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>