We recently switched the CI to not disable ptest, but this breaks builds
that use the GCC binaries built by Arm (external-arm-toolchain). This is
because the external-arm-toolchain recipe can't build packages for the
target, and the standard oe-core gcc recipes assume that they're being
built with themselves and make assumptions, specifically that libunwind
was enabled and headers can be copied directly from the sysroot.
This is a bigger problem that should be solved somehow, but for now we
can just remove ptest in the external-gccarm CI jobs which removes gcc
from the builds (it comes in via elfutils-ptest RDEPENDS).
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Add YAML language server comments so that IDEs know what schema to use
for the Kas files.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Temporary workaround for a number binaries in the toolchains that are
using 32bit timer API. This must be done in the CI yml file instead of
the recipe because of all the libraries in the toolchain have the issue.
Signed-off-by: Jon Mason <jon.mason@arm.com>
I misunderstood how the external-arm-toolchain recipes were working, the
latest revision of the recipe works with both 10.3 and 11.2.
Clean up my mess by dropping the PREFERRED_VERSION from the CI, and revert
the addition of versioned recipes. Simply using the right tarball is
sufficient.
Thanks to Sumit Garg for noticing my mistake.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The 11.2 release of the Arm GCC uses Broadwell-onwards instructions, but
our CI (and many other users) have pre-Broadwell hardware.
Until 11.3 is released which fixes this, go back to using 10.3 for our CI.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
In a distributed, non-homogeneous CI setup, the binary-toolchain setup
script might not run on the machine that needs the toolchains. Make
this per-build and it will always be there, at the expense of running on
builds that might not need it (though it still should be fast).
Also, there is an issue with the directory where the binary toolchain is
located being global, and racing against other systems using, setting up,
and tearing down. Link this to a local directory to avoid any races.
Signed-off-by: Jon Mason <jon.mason@arm.com>
Abstract away all of the things preventing the current setup from
working on only internal, arm64 build hardware.
Change-Id: Ib8d0e8e76602d4553e044520a91349015b1aa19b
Signed-off-by: Jon Mason <jon.mason@arm.com>
Ross Burton
Jon Mason
Khem Raj