meta-arm-systemready was intended to allow people writing BSPs to run
the SystemReady Architecture Compliance Suite[1] within the Yocto build
environment. However, whilst this seems like a good idea, there are
several problems:
- This layer only supports the IR band and v2 of the ACS. The ACS is now
at v3 and the bands altered, so there is no value in running obsolete
tests.
- Execution of the tests takes a long time, we have integration to run
the tests on a virtual fvp-base machine but execution takes many tens
of hours (our CI times out after 12, on a high-performance worker).
Running the tests in CI, and in particular inside BitBake, isn't
obviously the right thing to do.
- Execution on the tests on real hardware is not trivial, as testimage
has virtual targets as a primary usecase. It is unclear if anyone has
managed to use this layer on physical hardware.
Because of these issues, remove the layer. There are better integration
points for automated ACS testing, and this integration is obsolete.
[1] https://github.com/ARM-software/arm-systemready
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>
Setting an API key means we get higher rate limits. Because keys are
private, the key must be set in the environment of the runner.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Add a Kas fragment to enable the CVE checker. Disable warnings by
default but show them for the layers in meta-arm, because we only care
about meta-arm issues in this CI.
Explicitly hide kernel warnings as the kernel typically has tens of open
CVEs, and if we're carrying a kernel explicitly then it's typically an
interim kernel between releases.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
