Any image that inherits qemuboot must also add image dependencies on
qemu-system-native and qemu-helper-native, otherwise the image won't
be able to be booted.
Currently this is done by conf/machine/include/qemu.inc, but not every
machine that uses qemuboot includes that file.
Move the EXTRA_IMAGEDEPENDS from qemu.inc into qemuboot.bbclass, so that
the dependencies don't have to be duplicated.
(From OE-Core rev: dd54cf058f632e985917ff227483995f368e6a7d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now both gcc and clang all support -march=loongarch64, so we can use it.
(From OE-Core rev: acc08582293709c73011083aa7d5c631a9ae8c8c)
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3 interprets string literals as Unicode strings, and therefore
\s is treated as an escaped Unicode character which is not correct.
Declaring the RegEx pattern as a raw string instead of unicode is
required for Python 3.
(From OE-Core rev: 662f52f1713c9f070550fc0c874eb62312218ea4)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
feature-microblaze-versions.inc#
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Description: now we can tune our build only for power7 or power9
processor for PowerPC arch, this patch add posibility to choose power8 tune.
(From OE-Core rev: 10f7eeafd16c8b825b3c9b96b8433311f122df1e)
Signed-off-by: Aleksey Smirnov <aleksey.smirnov@yadro.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for SVE2 and add to 8-2a, as it can be used there.
Also, clean up the comments
(From OE-Core rev: 683443d57cb18b3b54245b1a09b6e5d2bae4f5d0)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to specify cortexr52hf to get a version that enables the
hard-float calling convention.
(From OE-Core rev: be83bc937a76efaead4690237db25459a57673fc)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to specify cortexr5hf to get a version that enables the
hard-float calling convention.
(From OE-Core rev: 992149023a896ecb38d07c54fa9ae9df82249a07)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently hard-float is dependency upon the special TUNE_CCARGS_MFPU which
contains custom -mfpu= values. However, newer 32-bit architectures like
cortex-r52 use 'simd' instead. There is no 'simd' entry for -mfpu=
according to the GCC manual, it's more or less automatic based on the
cpu settings.
Add this as an exception to the TUNE_CCARGS_FLOAT setting of hard or softfp.
(From OE-Core rev: f122eb8b19528e1192fd0b68b0639d84aa288155)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current include logic goes into generic arm v8/v9 architecture tunes and
adds corresponding -march option after synthesizing it from various tune
fragments, this is fine for a machine which is using armv8/armv9 based
tunes but cortex tunes are intentionally using -mcpu option based on
selected tune value. So when cortex based default tune is selected for a
machine, it will add both -mcpu and -march to the compiler commandline
which can result in invalid combinations for this pair in gcc's own
logic. This can then result in compiler warnings/errors reporting this
e.g.
aarch64-yoe-linux-gcc -mcpu=cortex-a72.cortex-a53 -march=armv8-a+crc+crypto -mbranch-protection=standard
...
cc1: error: switch '-mcpu=cortex-a72.cortex-a53' conflicts with '-march=armv8-a+crc+crypto' switch and resulted in options '+crc+crypto' being added [-Werror]
This is seen in lot of configure test results in glibc 2.39 and the
warning is promoted to errors by gcc in some of these checks especially
with gcc-14, the logs also show it as warning in other places in
configure checks.
mcpu option will compute relevant march implicitly as it specifies a cpu
implementation and this will be the right value to use, therefore do not
specify -march when -mcpu is already describing the cpu.
(From OE-Core rev: e64f0c1b6ac5d598a79a21de5f3060f83cb9523e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Ross Burton <ross.burton@arm.com>
Cc: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As per the Arm ARM section A2.3.2, FEAT_CRC32 is mandatory in Armv8.1
onwards, so there's no need to have an explicit optional tune for it.
SVE (which was a choice here) and SVE2 (which was not) are both optional
with v9.0, but GCC's -march=armv9-a defaults to enabling both SVE and
SVE2 on the grounds that there are no implementations of Armv9 that
don't support SVE2. This means there's no point having an explicit sve
feature as it's enabled out of the box.
(From OE-Core rev: 28fabebf812cdf8e76eb508115a4b76944f1e729)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
machine features like vfat are needed for ptests to pass ( e..g. parted)
This brings it closer to what x86 qemu config looks like as well.
(From OE-Core rev: a6d97ecb25567ec7e56c061be9ab281b54b4d524)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The conditional for the DTB nomenclature hasnt changed
and the 4.7 kernel is old enough at this point, hence
this check has become unnecessary'
(From OE-Core rev: f5dee6290ca750519455e311e429951b8eb7301b)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need for this variable anymore, as all consoles listed in
SERIAL_CONSOLES are checked for their existence before a getty is
started.
(From OE-Core rev: 8a1060952f8b6956acf747f3853401ac8a981fc3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This disables Nagle's algorithm for our tcp serial connections which may
be causing data transfer issues.
(From OE-Core rev: f8eff4c427881a98333fdf7c42f66ed6603e4f03)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop the version overrides for the kernel for the x86 and arm machines
so we can go back to following the distro versions. The reasons for
these versions is mostly historical at this point as the issues were
resolved.
(From OE-Core rev: 298fa078fab58b64246376ffd70ad6a0c7589876)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The modesetting driver works well in qemu, so install it by default. The
plain framebuffer has been buggy in recent 6.4 kernels, a sign that it's
not getting much testing. The Xorg modesetting driver that can use more
powerful virtualised hardware is much better.
We override the default XSERVER because we want to pull in the GLX
extension to exercise that.
(From OE-Core rev: 7b5fc42488a514bf51d49ee5274731c6432efd1b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If virtio-serial-device is used, the following error occurs on loongarch64:
qemu-system-loongarch64: -device virtio-serial-device: No "virtio-bus" bus found for device "virtio-serial-device"
(From OE-Core rev: 08734ec0c2083e90207559ecc659809b86b8779d)
Signed-off-by: Zang Ruochen <zangruochen@loongson.cn>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to x86, ensure we have the flags to the linker operating correctly (it
defaults to 32 bit). Normally it is driven by gcc so this hasn't shown up but
it does lead to hundreds of binutils test failures.
(From OE-Core rev: 2cf9013fd8df2bb67f93ffd44ccc23453cedf42a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure the CPU enabled in QEMU is correct for this architecture.
(From OE-Core rev: 6e0d176c4ce2bbbd975b74e41f63e60df7e3a554)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 6.4 kernel causes parselog failures when Xorg starts:
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" not found
It appears to be specific to qemuarm without GL. Until this is resolved,
pin the qemuarm BSP to 6.1.
(From OE-Core rev: 28615ad284243db4465c843c456083c9d4b3a0c4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable branch protection (PAC/BTI) for all aarch64 builds. This was
previously enabled at a global level in the GCC build, but that breaks
the gcc test suite.
(From OE-Core rev: 8905639d1cdc5ce809cc5ecd9672f5e86bf8a579)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 5c6064 the qemuarm* machines gained vmalloc=256, because in testing
Bruce was seeing problems when the vmalloc area was too big for the
memory size of the machine (eg 256MB).
The intention was for the area to be very small, but 256 bytes is too
small and the kernel sets a minimal vmalloc area of 16MiB:
[ 0.000000] vmalloc area is too small, limiting to 16MiB
However, a 16MiB area is too small and results in pages of messages when
you try and use the system:
[ 242.822481] vmap allocation for size 4100096 failed: use vmalloc=<size> to increase size
There have been a number of changes since this commit, remove the
explicit vmalloc argument and use the default. I've tested that the
system still boots locally.
[1] early_vmalloc(), https://elixir.bootlin.com/linux/latest/source/arch/arm/mm/mmu.c#L1170
(From OE-Core rev: 816dd95320ba2e4a0f6b816e4f58999c0f235ae2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To test nested kvm with qemu QB_CPU* needs to be modified.
E.g. set to "-cpu Haswell-noTSX-IBRS,vmx=on"
This allows to overwrite this from local.conf etc.
(From OE-Core rev: aa9d145d90893b04cde197e9b5f4dc574e4738e1)
Signed-off-by: Thomas Roos <throos@amazon.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was missed when riscv64nc was added
(From OE-Core rev: 0c549ef5732afdcd96407ceb045983eed2ca75f4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow a user to override the QM_SMP value giving them the opportunity to
select for themselves the number of CPUs to use in qemu.
(From OE-Core rev: 70a91e6d0357149c00b97f7e66e16cbc52997a92)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
6.1 has been soaking for a while now, so it is time to bump the
default qemu version to 6.1 and prepare to remove 5.19.
(From OE-Core rev: 91c1f7d4eb9ec5ad683c798812395df3a56747ba)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On master oe, build a qemuppc64 with systemd as default init, when we
use nfs bootup, the kernel might panic due to missing symbol in dynamic
libraries as below:
hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0
/sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2)
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1
Call Trace:
[c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable)
[c000000007443be0] [c000000000103524] panic+0x170/0x3cc
[c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50
[c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0
[c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30
[c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0
[c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250
--- interrupt: c00 at 0x7fff9ed9e840
NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000
REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard)
MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000
One or more of the libraries systemd depends on failed to load due to
unresolved symbols/functions. This was intermittent - with a failure
rate estimated between 5% and 30%.
After checking the code, this issue happens on gcc 12, kirkstone is using
gcc 11 works well, with both using the exact same v5.15.84 kernel commit.
There is a kernel fix from upstream [1], they changed the rsize / wsize
to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's
default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have
its own linux-yocto kernel branch, so apply this change might cause
regression with other platforms which share branch with qemuppc64.
So, we added an extra option for nfs rootfs, and set the qemuppc64 default
r/w size to 524288 to line up with the kernel fix[1].
Yocto did a similar thing in the distant past[2] - prior to boot-arg
adjustments existing - by allowing a Kconfig to set the defaults on
nfsboot, in order to work around hardware limitations.
Reference:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf
[2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95
(From OE-Core rev: 14a81556ff1be326647e654424c8f1bf9d0db912)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use Skylake-Client to match QB_CPU_KVM as changed in:
https://git.openembedded.org/openembedded-core/commit/?id=6f2af1e5d1537b4d31e14946292bf58f0fd76fc9
* explicitly set -cpu instead of letting qemu to choose based
on host cpu
* check=false is still useful as e.g. on on AMD Threadripper 3970X:
orc/0.4.33-r0 $ PSEUDO_UNLOAD=1 qemu-x86_64 -r 3.2.0 -cpu Skylake-Client -L recipe-sysroot -E LD_LIBRARY_PATH=recipe-sysroot//usr/lib:recipe-sysroot//lib
orc/0.4.33-r0/build/meson-private/sanitycheckc_cross.exe
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
* if this still doesn't work for you on your host, you might need to downgrade
DEFAULTTUNE to e.g. corei7-64 (all all the way back to core2-64), for
more details see:
https://www.openembedded.org/pipermail/openembedded-core/2018-April/150178.html
* the leading space shouldn't be needed, I've kept it for consistency
with other QEMU_EXTRAOPTIONS
(From OE-Core rev: d1a52559670921389a66a4c26d37481d6611042a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Effectively revert "qemux86-64: build for x86-64-v3 (2013 Haswell and later) rather than Core 2 from 2006"
(commit 6f2af1e5d1537b4d31e14946292bf58f0fd76fc9)
Much as I'd love us to use the latest tuning, we do have some autobuilder
hardware which isn't ready for this yet which breaks KVM and some qemu
user mode usage as there appear to be TCG bugs too. I suspect we're not
the only ones with such hardware.
Drop the tune back to core2-64, anyone can easily customise it
themselves if they need it. We can revisit this in a year or two
as we should be ready then. It has beena good test of the rest of the
support which all seems ready.
I'd have preferred to use corei7-64 but that causes
runqemu.RunqemuTests.test_boot_machine_iso to hang.
Leave the newer tune file inclusion so people can change tunes
more easily.
(From OE-Core rev: 369b1dfa28b1791d45f068acc765190defecd460)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows us to
- test those more recent instruction sets (AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE)
- benefit from improved performance across the stack both in kvm-driven system emulation and when running
on real silicon.
For example, glibc:
https://www.phoronix.com/news/Glibc-strcasecmp-AVX2-EVEX
v4 level is adding AVX-512, which is far less established, particularly Intel has famously backtracked
from supporting it in Alder Lake/Raport Lake client CPUs and AMD has only implemented it in very recent Zen4 products:
https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels
(From OE-Core rev: 6f2af1e5d1537b4d31e14946292bf58f0fd76fc9)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Qemu 7.2 finally allows us to move beyond building for original Core 2/Core i7 era hardware,
and this patch adds support for the newer generations. But first, a bit of
background:
Recently toolchains gained support for specifying x86-64 'levels' of
instruction set support; v3 corresponds to 2013-era Haswell CPUs
(and later), with AVX, AVX2 and a few other instructions that
were introduced in that generation. I believe this is preferrable
to picking a specific CPU model as the baseline.
Here's Phoronix's feature article that explains the feature and the available levels:
"Both LLVM Clang 12 and GCC 11 are ready to go in offering the new x86-64-v2, x86-64-v3, and x86-64-v4 targets.
These x86_64 micro-architecture feature levels have been about coming up with a few "classes" of Intel/AMD CPU processor support rather than continuing to rely on just the x86_64 baseline or targeting a
specific CPU family for optimizations. These new levels make it easier to raise the base requirements around Linux x86-64 whether it be for a Linux distribution or a particular software application where
the developer/ISV may be wanting to compile with greater instruction set extensions enabled in catering to more recent Intel/AMD CPUs."
https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels
Here's gcc docs for it:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
And here's the formal specification (click on the pdf link):
https://gitlab.com/x86-psABIs/x86-64-ABI
The actual tune file was created by copying corei7 tunes and doing
search/replace on them. Qemu options were dropped as unnecessary.
32 bit tune was dropped as well, as there is no 32 bit only CPU
that also supports these new instructions; all of the v3 capable
chips are 64 bit.
(From OE-Core rev: ac041f90e71dba83b7144c91f929de88aaeae519)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We supported neoversen2 base on armv8.5a in the past, add tune include
for armv9a and support neoversen2 base on armv9a.
(From OE-Core rev: 4a2c4cfaaa5a6d7175c81064939e21bcfe3e736a)
Signed-off-by: Ruiqiang Hao <Ruiqiang.Hao@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Back in 0be64e54a0e6 ("qemux86: Allow higher tunes") we moved the
qemux86 machine to using the core-i7 tune file, for maximum flexibility
and to allow for enabling advanced processor features if desired or
required by various packagess, without changing the default tune. Do the
same now for qemux86-64.
Cc: Joshua Watt <JPEWhacker@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: a7411f5964f2e8384768b0a5e67817b3adc0ae8c)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
v5.19 is the latest reference kernel, we bump our qemu machines
to use it by default.
(From OE-Core rev: 8f3b5cab696704fdc2060c710e3429859736a63a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-core previously carried patches to glibc that added optimized sqrt
implementations for various PowerPC chips. These were recently removed,
which now results in errors when compiling glibc with certian PowerPC
machine tunes:
checking sysdep dirs... configure: error: The 603e subspecies of powerpc is not supported.
Remove setting GLIBC_EXTRA_OECONF with parameters that are no longer
valid. Also remove a commented out setting of the variable that probably
isn't vaild anyway.
Fixes: 2511e937f445 ("glibc: Drop ppc sqrt optimisations")
(From OE-Core rev: 40f15066c24720aae36713c9856ffb4fae146a45)
Signed-off-by: Robert Joslyn <robert.joslyn@redrectangle.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add tune include for armv8.4a. This adds support only for bare armv8.4a
(and for crypto extension). There is no support for additional
instructions added by architecture extensions (except the main crypto
extension support).
(From OE-Core rev: 39743abada4a2459c74831aa78930de5461adee2)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These devices are historical, modern Linux will just use the USB
devices, and occasionally the init of these devices fails:
atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
psmouse serio1: Failed to reset mouse on isa0060/serio1: -5
Explicitly add a USB keyboard to go with the USB tablet, and disable the
i8042 entirely.
[ YOCTO #14718 ]
[ YOCTO #14743 ]
(From OE-Core rev: c01f47003f34b9ad2fe3d17e1ead84c27ee1e57d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The virtio PCI devices seemed to be required for this machine for some
versions of qemu (based on errors from running qemu saying that the
devices don't exist). Changes to the entries here is all that is needed
to get it working.
(From OE-Core rev: 217deeb43036d1a046d6c5ea2c1ccdb94d3d605a)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in making mouse response better where transition between host
and guest mouse is abrupt and not precise and as a result its difficult
to access stuff near the edges.
(From OE-Core rev: 010287147d2205790745e6dab8e955e71bc7cac2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
