| Age | Commit message (Collapse) | Author |
|---|
|
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
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>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Ensure we turn on edid for the VGA display which fixes a hang with the
5.0 kernel for qemuarm64.
Thanks to Jon Mason for the fix.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add new QEMU BSP for a Arm Cortex-A15 system and use this as qemuarm,
moving the old armv5te Versatile PB based machine to qemuarmv5.
The new machine uses the QEMU virt machine type, which should be
faster to emulate and updates the qemuarm support to a modern
architecture.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For multilib to work correctly, BASE_LIB overrides must be provided.
Signed-off-by: teven Hung (洪于玉) <Steven.Hung@mediatek.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
"cortexa53" -> "cortexa35"
Signed-off-by: Steven Hung (洪于玉) <Steven.Hung@mediatek.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add the necessary parts to qemuarm64.conf for graphics to be shown in
the SDL window, and USB so that it is possible to interact with it.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add comments describing what is going on, remove an unnecessary space,
remove a duplicate comment, and increase the serial speed.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For multilib to work correctly, BASE_LIB overrides must be provided for
each new tune added in this file.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some ARM Cortex devices have the VFPv4-D16, but no NEON.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It looks that the Cryptography engine is mandatory in this
platform.
https://developer.arm.com/products/processors/cortex-a/cortex-a72
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It looks that the Cryptography engine is mandatory in this
platform.
https://developer.arm.com/products/processors/cortex-a/cortex-a53
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
https://developer.arm.com/products/processors/cortex-a/cortex-a35
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
https://developer.arm.com/products/processors/cortex-a/cortex-a32
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
I am not familiar with the big endian, so I don't update it.
I don't have much information about the Cavium ThunderX,
it looks like it supports all the ARM instructions.
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
arch-armv8 does not have many real-world implementations
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are some addtional instructions apart from bare armv8,
also there is armv8.1, armv8.2.
Most the processor would support crc, except X-gene 1.
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
tune files which inherit the arch definitions already define appropriate
-mcpu option, which is equivalent of right -march and -mtune combination
and is preferred since gcc is getting stricter and stricter with option
check semantics and can now find incompatible -march and -mcpu options
better with every release. It does internal feature consistency check
and if it finds out discrepency between what -mcpu would expand to as
compared to -march it will flag the options to be incompatible, for
naked eye it sounds wrong but gcc would translate -mcpu to a given
-march internally and it might not match to what we set in these arch
files.
The effects are quite subtle, where this can result in configure test
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.
e.g. with gcc9 which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ ends up
disabled due to configure check failures e.g. size_t size, ptrdiff_t
sizes, which inturn results in compiling libstdc++ with unwanted
disabled features.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
-march=armv5't'e means that CPU can execute thumb ISA, we do not need to
tie this to exclusively generating thumb ISA, this change means that
when we have thumb in tune features then it can use 't' in -march
options irrespective of ISA being thumb or arm.
This fixes derivative of armv5 tunes and paves way for gcc9 where e.g.
armv5e is dropped and minimum arch supported is armv5te
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Historically first PowerPC ABI was big-endian only (elfv1 currently). It
is standard ABI for both 32-bit ppc and 64-bit ppc64 architectures.
With PowerPC little-endian support new ABI was introduced (elfv2) and it
is used primarily with ppc64le target only. While it has support for
big-endian it is not commonly used and elfv1 still preferred.
Musl does support only elfv2 ABI for both LE and BE and does not have
any plans to support elfv1.
Since then to build for powerpc64 with musl new ABI should be used. As
expected it is not compatible with elfv1 but that isn't problem as long
as there is no binary distributed software or assembly code written for
elfv1 ABI.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The QEMU usermode fails with invalid instruction error when
used with those tunes.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It is ppcpX, not ppcprX, where X is 6 or 7. While there select 32bit
tune for P5 machine to bring it inline with P6 and P7.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Just adding `-device virtio-rng-pci' to the QEMU invocation will
add the device with a default host backend. As of QEMU 1.3+,
the default backend is to use the host's /dev/random as a
source of entropy. [1]
When the entropy pool is empty, reads from /dev/random will
block until additional environmental noise is gathered. [2]
For Yocto, if call runqemu frequently, it will consume lots
of host's /dev/random, and kernel finish crng init in guest get
more and more slowly.
Here are 4 times runqemu boot test:
[ 3.464432] random: crng init done
[ 20.874030] random: crng init done
[ 23.583589] random: crng init done
[ 23.858945] random: crng init done
Modify entropy source to /dev/urandom device on the host which
returns random bytes using a pseudorandom number generator seeded
from the entropy pool. Reads from this device do not block and
kernel finish crng init in guest will not delay.
Of course, the side effect is obviously, we lost the quality of
randomness, but the modification is only on runqemu script
rather than real embedded device, and it benefits oeqa efficiency
in which many cases call runqemu especially multiple oeqa builds
on one host.
After apply the fix:
[ 3.364670] random: crng init done
[ 4.619061] random: crng init done
[ 3.403897] random: crng init done
[ 3.450717] random: crng init done
[1] https://wiki.qemu.org/Features/VirtIORNG
[2] http://man7.org/linux/man-pages/man4/random.4.html
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
*The PowerPC SPE support is split off to a separate powerpcspe port
Signed-off-by: Chunrong Guo <chunrong.guo@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
configuration
If you try to build a system with multiple BSPs, one of which is qemux86
or qemux86-64, the gstreamer package will change. This will trigger
anything using gstream to also be rebuilt.
For a package based system, the PR values will also be incremented each
time. The end result will be an ever growing set of PR values as well as
being unable to tell which configured version of the multimedia components
are really being deployed.
These therefore belong in the machine configuration.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch adds tuning for the mcf5441x ColdFire family.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes warnings in builds using core2-32 tune:
warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11]
warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm [bit 29]
when executing postinsts using qemu-i386.
i386 target doesn't enable CPUID_EXT2_SYSCALL and CPUID_EXT2_LM [1]
while cpu choice of core2duo that we use for core2-32 TUNE does [2].
Use n270 cpu instead to use with qemu which supports SSSE3 and doesn't
have these bits enabled [3].
[1] https://github.com/qemu/qemu/blob/master/target/i386/cpu.c#L739
[2] https://github.com/qemu/qemu/blob/master/target/i386/cpu.c#L1439
[3] https://github.com/qemu/qemu/blob/master/target/i386/cpu.c#L1603
Fixes [YOCTO #12916]
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
4.18 is replacing 4.15 as the latest kernel in the upcoming
release, so we update our preferred versions to match.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SERIAL_CONSOLE was already deprecated in 2013, yet still some
machine configuration files were using it. This patch replaces
it with SERIAL_CONSOLES, which is the successor.
The default value in systemd-serialgetty.bb can also be safely
transitioned from SERIAL_CONSOLE to SERIAL_CONSOLES, as this
recipe already uses SERIAL_CONSOLES within do_install().
The documentation seems to be already up do date.
beaglebone-yocto.conf in the bsp-guide already uses
SERIAL_CONSOLES. The ref-manual redirects from SERIAL_CONSOLE
to SERIAL_CONSOLES.
[YOCTO #12653]
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
qemumips,qemumips64 and x86 based machines include kernel-modules by
default. Remove the kernel modules from RRECOMMENDS to make it consistent
across the machines.
Tested using core-image-sato on qemumips, qemumips64, qemux86 and
qemux86-64
[YOCTO #12383]
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add U-Boot machine configuration for the qemux86 and qemux86-64
to allow building U-Boot on those targets. This in turn allows
the auto-updater to update the U-Boot recipe.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Ross Burton <ross.burton@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Although there may still be specific cases which can benefit from the
ARM instruction set, the Thumb2 instruction set is generally a better
default for armv7a class CPUs. Distros such as Debian and Fedora have
been targeting Thumb2 by default for some time.
Note that setting ARM_INSTRUCTION_SET has no effect unless
TUNE_FEATURES contains "thumb" (which is controlled by the "t" suffix
in DEFAULTTUNE, e.g. armv7vehf-neon -vs- armv7vethf-neon, etc) so out
of tree machine configs may need to update their DEFAULTTUNE to take
advantage of this change.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The logic can be improved and the historical NOISO/NOHDD variables
moved into the class and out of common code.
The variables are also then removed in favour of directly controlling
the behaviour from IMAGE_FSTYPES in line with all the other image types.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When runqemu is invoked with an image type (wic, hddimg etc) as a parameter,
the kernel value and command line parameters from qemuboot.conf
are ignored and not passed to qemu cmdline.
As an example, when using:
$ runqemu wic kvm
It results in no network interface and video mode warnings when qemu is up because
the -kernel and -append options were not passed.
Change qemu conf to use qemux86-directdisk.wks that supplies the kernel parameters
that are appended to the bootloader configuration when generating qemu wic
images instead of relying on qemuboot.conf.
Fixes [YOCTO #12224]
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently we have local.conf included before qemu.inc, and ${DISTRO}.conf
after qemu.inc. They both possibly specify their expected kernel providers.
To let other config files override it in real use, this commit changes
kernel provider assignment to ??= .
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The gcc "corei7" CPU type was last documented in gcc 4.8.x and has
been undocumented from gcc 4.9.x onwards:
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.html
https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/i386-and-x86-64-Options.html
Although it still seems to be accepted by gcc 7.x, it's likely to be
deprecated and removed at some point. To preempt that, switch the
corei7 TUNE_CCARGS -march CPU type to "nehalem", which is the closest
replacement (and matches the CPU type already being passed to qemu).
Since the tune-corei7.inc include file is intended to cover a range
of CPUs from Nehalem onwards, switch the TUNE_CCARGS -mtune option
from "corei7" to "generic", which instructs gcc to produce code
optimized for the most common IA32/AMD64/EM64T processors.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Define cpu type for Qemu in QEMU_EXTRAOPTIONS.
Otherways Qemu will emulate some virtual qemu32/64 processor,
which has very basic set of features, and programs built
for later CPU may crash, due to lack of new features (e.g. SSSE3).
Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Ensure that the qemu* machines are building the latest available
kernel in master.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There isn't currently any tune available for i686 x86 optimizations.
The tune for i586 doesn't enable i686 specific optimizations, and the
one for core2 enables things that won't work on a i686 CPU (like SSE3).
Make the tune for core2 inherits from this one and move there the
setting of X86ARCH32.
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The kernel class now sets RDEPENDS_${KERNEL_PACKAGE_NAME}-base so this include
needs to do the same, otherwise bitbake emits a warning and the kernel isn't
removed.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Add architecture and tune includes for MicroBlaze. This covers
architecture configuration as well as tune configuration and features.
The Xilinx MicroBlaze architecture is a soft-core CPU architecture
designed for implementation on Xilinx FPGAs. Because the CPU is a
soft-core it can be configured differently depending on resource and
performance constraints which affect the ABI and supported instructions.
The architecture is also used in other Xilinx products where the core is
implemented as part of fixed silicon (e.g. Xilinx ZynqMP).
The default tune include 'tune-microblaze.inc' provides the baseline (no
features enabled) tune configuration for a target machine. This is
similar to other architectures such that the machine.conf includes a
tune-*.inc. However due to the customizability configuration is
specifically handled on a per machine basis. A machine should configure
the available tune features by setting the available features directly
by appending to the 'TUNE_FEATURES_tune-microblaze' variable.
This tune configuration approach is preferred to avoid the definition of
an otherwise large set of possible tune configurations for the available
features (14 CPU versions and 11 feature configurations), which would
otherwise require >1024 predefined tune configurations.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
In case some users want to use linux-yocto-rt as the preferred kernel.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This was included to allow hwrng to feed data to /dev/random. Since the
kernel does this itself (confirmed by the recent kernel Kconfig text change
, code inspection and local testing), we can drop rng-tools from these
images.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The trailing space added to TUNE_CCARGS when appending -mfpu=XXX is
unnecessary and leads to a double space in the final value.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This is needed as an x32 more generic x32 override later in the
OVERRIDES, currently linux-gnux32 is the first override, but we
need a stronger (later in the list) x32 override to deal with some
needed x32 dependency overrides.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Khem Raj
Bruce Ashfield
Richard Purdie
Jon Mason
Steven Hung (洪于玉)
Mike Crowe
Phil Edworthy
ayaka
Serhey Popovych
Hongxu Jia
Chunrong Guo
Angelo Dureghello
Anuj Mittal
Bruce Ashfield
Maciej Pijanowski
Maxin B. John
Marek Vasut
Andre McCurdy
He Zhe
Ruslan Ruslichenko
Ross Burton
Carlos Alberto Lopez Perez
Nathan Rossi
Ming Liu
Saul Wold