Now that the 5.4 recipes are available, we bump the default versions
to use them.
(From OE-Core rev: c250dbd2a68048f83837e7cbdfb53bc38623e4a2)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I am not sure if this has ever worked, but uvesafb is a really
outdated (VBE from the 1990s), awkward (needs v86d) and limited
(no support for high resolutions) way to do it.
The specific reason 640x480-32 was introduced (ages ago) was
to force 32 bit mode with vmware driver, as 16bit had rendering issues.
The modern, supported option is video=... kernel parameter documented here:
https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDIDhttps://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst
which can be passed directly to runqemu and doesn't require special
kernel modules.
Sato under X will continue to use 640x480 as that is hardcoded into
xorg.conf under qemu.
(From OE-Core rev: 1cf26f69fd89b43be24cd1232c43e5050b9d718a)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was added ages ago to enable GL passthrough with
vmware driver, and is no longer relevant, as std or virgl is used
instead nowadays.
Original commit:
commit 072545b111
Author: Richard Purdie <rpurdie@linux.intel.com>
Date: Wed Jan 21 17:40:51 2009 +0000
scripts/poky-qemu-internal: Add support for GL passthrough in qemux86 images
(From OE-Core rev: 857078ba8eda153f4a097683db551a7d310ecc01)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
running ptests on qemuarm returns fails since it finds errors in kernel
logs like below
***********************
Central error: [ 4.338465] pci-host-generic 4010000000.pcie: ECAM ioremap failed
***********************
Since its a 32bit kernel 4010000000 address is truncated to 10000000 and ends up
in conflicts with VIRT_PCIE_MMIO, which ranges from 0x10000000 to 0x3efeffff
This is happening because the linux-yocto kernel is not compiled with
LPAE support, however, virt machine for qemuarm assumes that by default
Should LPAE be enabled by default in kernel config is a separate
question
(From OE-Core rev: 4486f4523f6671841ffa65ce2419b9e3e018ad76)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various += were used, refactor these to be either = or .= depending on
usuage.
CONFLICTS should be '=', as no leading space is required and they are not
amending any other conflict settings.
The TUNE_CCARGS should be .= so that if the feature does not define a CCARG
blank spaces are not added to the CFLAGS. This is consistent to how the arm
tuning is implemented.
(From OE-Core rev: 78c38857486d3107ecd95d0ceefabcf5152c3928)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to allow no version to be configured. This should use the GCC default
which is the latest defined version, currently 11.0.
(From OE-Core rev: 0d1551dcc169f2d8dbfbe01b4f1f0ae3ce4770ed)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using microblazeeb breaks a number of autoconf recipes, including newlib
components. 'microblaze' is defined as the big-endian version, while
microblazeel is defined as the little-endian version.
config.sub: 2018-07-03
...
| maxq | mb | microblaze | microblazeel | mcore | mep | metag \
...
| microblaze-* | microblazeel-* \
...
microblaze*)
basic_machine=microblaze-xilinx
...
(From OE-Core rev: c052b0c984b28d64527a66ea8e2936ca28b9406f)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is beneficial for parted ptests in particular as they
make use of vfat, and fail otherwise.
(From OE-Core rev: ffbc6dc213abf96b816fc9dd87766c3a36935c2a)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in booting weston images ( core-image-weston ) with fbdev
backend, without this westons initialization of fbdev backend fails
because it does not get correct frame buffer settings and exits
pre-maturely
(From OE-Core rev: d95b03ae45b36a9b127ef639322e61b21c328d87)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in constructing right arch for target tuple name for
Little-endian ppc
(From OE-Core rev: b6ac40f1cbabb20896bf113568f7735a462ed1a6)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use wic instead of the live/hddimg filesystem type for x86 machines, as it
produces better filesystems and doesn't have a hard limit of 4GB.
(From OE-Core rev: 04e4e93efa4d8e2bdde950fe95c2fd95f89c13e7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the following errors for newlib and baremetal libcs:
ld: unrecognized option '--hash-style=sysv'
ld: unrecognized option '--hash-style=gnu'
(From OE-Core rev: 8ae998fa8dd216d008cc9ddbea98bbb945501e41)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
clang 9.x ( which is now default in meta-clang ) supports riscv
(From OE-Core rev: 198689f74915756ce6ae38d6735780a26e9b3f7e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
commit 3613b2780a6b5d5d70ea6802be5060a8214cbdb5 from
git://github.com/renesas-rcar/meta-renesas
The renesas rcar SoC H3/M3 is big.LITTLE architecture(cortex-a57.cortex-a53).
In order to optimize the performance of the code running on SoC H3/M3,
add a tune file for ARM Cortex-A53-Cortex-A57.
Create this tune file by refering GCC doc, 3.18.5 ARM Options.
(From OE-Core rev: 7e0c9290a9971b92bcb313742f126ca7488d91c3)
Signed-off-by: Meng Li <Meng.Li@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since TUNE_FEATURES now either contains a CPU or an architecture (but
not both) we can't rely on finding the architecture in TUNE_FEATURES.
Use architecture specific over-rides instead.
(From OE-Core rev: 805dd4807d322dc70cef97edd68fdb3142b60fb1)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows us to generate a rootFS with a large filesystem for use with
QEMU.
(From OE-Core rev: e06439200e44999c1e2f88d7d6c651da13698ca7)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default riscv is little-endian moreover most of other arches define
bigendian as tune and treats absense as litteendian, this make risc-v
fall in line
(From OE-Core rev: cd6f377591a7bd7b3c61ce580f997aaeffab3df3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in defining LE tunes and at the same time specifies
endianness on compiler cmdline clearly, clang e.g. defaults to
little-endian always, so unless specified with -mbig-endian won't
compile the code right
(From OE-Core rev: e0fd699d398f0e88fb208970dea7b74e6e9431fe)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was found to crash the X server on startup under qemu.
(From OE-Core rev: 045011ed29c0ab45892ad0881a4a8987f2adc977)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a discussion about what amount of RAM is appropriate for a
default; the outcome was that for now it is still 256M. Some qemu machine
definitions have however set this to 512M so for the sake of
treating all architectures fairly, they are reset back to 256M.
Also runqemu is adjusted to use 256M if QB_MEM is not set at all.
http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285900.html
(From OE-Core rev: 04c01b6cc5be3e6d45d0e04571640648a5655a8b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Configuration:
MACHINE = qemumips64
bitbake lib32-core-image-minimal
runqemu slirp nographic qemumips64 ext4
Error:
ERROR - Failed to run qemu: qemu-system-mips: unable to find CPU model 'MIPS64R2-generic'
Fixed by moving QB_SYSTEM_NAME to Respective configuration file
(From OE-Core rev: e724e8836ed614ff8eaa0d0d9c51d22ee62576b3)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have a -bios option for the RISC-V virt machine in QEMU we
can pass OpenSBI in via -bios and the kernel in via -kernel. We no
longer need to pass the kernel in via -device loader so let's remove
that.
(From OE-Core rev: 65e7f371f19e053d0bac7771a80615f6bada74c7)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Configrations:
MACHINE: qemux86-64
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Reproduce steps:
bitbake lib32-core-image-minimal
runqemu qemux86-64 nographic lib32-core-image-minimal
Errors:
qemu cannot bootup since:
Booting from ROM...
This kernel requires an x86-64 CPU, but only detected an i686 CPU.
Unable to boot - please use a kernel appropriate for your CPU.
QEMU: Terminated
For lib32 image, override has x86, so the qemubin set to qemu-system-i386,
fix by move QB_SYSTEM_NAME to corresponding conf, don't use the override
(From OE-Core rev: ffaf86f175b2e6caa3a0067f7b3725930b053715)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The include is split ready to add the 32-bit RISC-V machine as soon as
glibc supports 32-bit RISC-V.
This is based on the work in the meta-riscv layer, thanks to Khem for
starting this.
(From OE-Core rev: 11b6020dff4550fc3a42e04bc1e86baf37942c62)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The value of PACKAGE_EXTRA_ARCHS_tune-thunderx should be based on
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto instead of armv8a-crc-crypto.
Otherwise we would get some sanity check error like this:
OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Error, the PACKAGE_ARCHS variable (all any noarch armv8a-crc-crypto thunderx qemuarm64) for DEFAULTTUNE (thunderx) does not contain TUNE_PKGARCH (aarch64)
(From OE-Core rev: 13cc0f7c0bd98ea228e9bdf51043117d38837ce7)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows kvm acceleration on arm systems that support it. "host" is the
best option I can find right now to attempt to use the acceleration. It
potentially might not be correct but arm systems are sensitive to the
correct values and I don't want to encode the autobuilders CPU type here.
(From OE-Core rev: f13788541f64774a586971ed57699e4397b38b32)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This matches what the qemux86_64 is currently using, and
will allow testing the instructions added in the meantime;
particularly various SSE extensions are now enabled.
(From OE-Core rev: f3b1e577ec94c849d0354f5679257f02ef4e4fe9)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allows the qemux86 machine to be tuned all the way up to an i7 if
desired by overriding DEFAULTTUNE. The default if unspecified is left at
i586.
This can be useful for enabling advanced processor features like SSE if
desired or required by various packages.
(From OE-Core rev: 0be64e54a0e67472eaff9c794a33d76971c9b1a3)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes sure, e.g., ${SOC_FAMILY} and ${MACHINE} have higher
priorities than aarch64.
(From OE-Core rev: 4d1339af88543d85930139dbcb87a669f285ea66)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The armv8a tune specific PACKAGE_EXTRA_ARCHS contained tune feature
names like "crc" and "crypto" rather than package architecture names
like "armv8a-crc" and "armv8a-crypto".
(From OE-Core rev: 1756f2354745ee709886683422887efed4e10dba)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Beautify the machine config files by making the names and descriptions
more uniform and verbose
(From OE-Core rev: 1108a24e2c58794163c8cf35154f8be5c1d06c29)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allows for mips32 multilib to be mips32r2, like qemumips.
(From OE-Core rev: 9713e8a5460ae81a33c6a727664f4cdb54fb1f0a)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SIMD instructions are a mandatory part of armv8a
(they were optional in armv7a), and the gcc docs
also say that they are always enabled.
(From OE-Core rev: 02288c94e99e9dd444d8c1af186b6d89085b7b8b)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armv5 is not a specific tune feature anymore, there is no need to check
it, since having dsp will define if 'e' should be added or not
(From OE-Core rev: 1d6d5bb30a83f9136b7c33e297d48564ae61b50e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
