linux/poky.git/meta/conf/machine, branch uninative-2.8

tune-cortexa72-cortexa53.inc: Adding missing TUNE_FEATURES

2020-02-28T23:11:29+00:00

Without the proper default tune in TUNE_FEATURES, certain variables won't expand correctly. MACHINEOVERRIDES won't add cortexa72-cortexa53: TUNE_CCARGS won't add -mtune=cortexa72.cortexa-53, generating the toolchain incorrectly. Adding missing 'cortexa72-cortexa53' to both TUNE_FEATURES_tune-cortexa72-cortexa53 and TUNE_FEATURES_tune-cortexa72-cortexa53-crypto (From OE-Core rev: eee65bed5ee39051541a0a3f2a311396d6e7326c) Signed-off-by: Jaewon Lee Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie

qemu: bump default reference kernel to v5.4

2020-02-22T23:57:27+00:00

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 Signed-off-by: Richard Purdie

qemumips: use std vga instead of cirrus vga

2020-02-21T09:39:00+00:00

This is what the upstream recommends nowadays: https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ I have verified that both X and weston continue to boot and look right; however xorg.conf file needs to be removed as it is cirrus specific and doesn't work and isn't needed with std vga. (From OE-Core rev: 96e6434239268fd0fc021bda9c8fedd998597097) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemux86: drop resolution setting via uvesafb

2020-02-18T23:53:54+00:00

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_EDID https://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 Signed-off-by: Richard Purdie

qemux86: do not add vga=0 to kernel parameters

2020-02-18T23:53:54+00:00

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 072545b1111c5efb66289a4866897429f5fcd969 Author: Richard Purdie 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 Signed-off-by: Richard Purdie

qemuriscv64: Set the Xvisor platform

2020-02-15T10:26:42+00:00

Set the platform information required to build Xvisor. https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/xvisor (From OE-Core rev: bd229106ffdb97a2d7e570a3b69147786569a29b) Signed-off-by: Alistair Francis Signed-off-by: Richard Purdie

qemuarm: Disable highmem when QB_MACHINE is virt

2020-02-14T13:07:23+00:00

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 Signed-off-by: Richard Purdie

microblaze tune: cleanup +=

2020-02-06T12:16:34+00:00

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 Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

microblaze tune: Enable 64-bit

2020-02-06T12:16:34+00:00

64-bit is not yet available in Linux, but some non-Linux uses exist. (From OE-Core rev: 389691be34b79da1fafa8df2e6369e7771406cc2) Signed-off-by: Mark Hatle Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

microblaze tune: Allow no version to be set

2020-02-06T12:16:34+00:00

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 Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie