Corstone1000 with Cortex A320 now uses the in-tree ethosu driver, so the
external meta-ethos layer (and its meta-sca dependency) is no longer needed.
Remove meta-ethos and meta-sca from the Corstone-1000 A320 kas
config, drop the layer dependency on meta-ethos, and stop
installing arm-npu-ethosu. Update the Corstone-1000
change log to reflect the removed layers.
Signed-off-by: Michael Safwat <michael.safwat@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The oe-core master branch just switched from whinlatter to wrynose[1] so
follow this change in our layers.
[1] oe-core cd1179544d7 ("layer.conf: Update to wrynose")
Signed-off-by: Ross Burton <ross.burton@arm.com>
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>
Enable the Corstone‑1000 Cortex‑A320 variant by:
- Introduce `machine/include/corstone1000-a320.inc` to configure the
default Ethos‑U MAC count when `cortexa320` is in MACHINE_FEATURES,
and allow override via `ETHOSU_NUM_MACS`.
- Add a KAS profile at `kas/corstone1000-a320.yml` for Cortex‑A320
FVP-based builds.
- Extend corstone1000.inc to detect MACHINE_FEATURES (cortexa320) and
pull in the matching tune-<core>.inc (default still Cortex-A35).
- Add the `meta-ethos` layer as a dependency of `meta-arm-bsp` for
Cortex‑A320 builds and define a new KMachine override to pull in
the Ethos‑U driver recipe.
- In `conf/machine/corstone1000-fvp.conf`, inspect `MACHINE_FEATURES`
and set `FVP_EXE` to `FVP_Corstone-1000_with_Cortex-A320` when
`cortexa320` is enabled, otherwise fall back to `FVP_Corstone-1000`.
- In `recipes-devtools/fvp/fvp-corstone1000.bb`, add a
`SRC_URI:cortexa320` entry (with checksums) for the Cortex‑A320 FVP
build archive.
- Disable the rootfs CPIO file compression so it is not compressed
twice when bundled with the kernel
Signed-off-by: Michael Safwat <michael.safwat@arm.com>
Signed-off-by: Frazer Carsley <frazer.carsley@arm.com>
Signed-off-by: Hugues KAMBA MPIANA <hugues.kambampiana@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
When images are repacked IMAGE_ROOTFS_EXTRA_SPACE is ignored.
This is not necessarily a bug but an undocumented quirk of how wic
works.
Evaluate IMAGE_ROOTFS_EXTRA_SPACE and use the value with the
--extra-space option. Note that, since IMAGE_ROOTFS_EXTRA_SPACE is in
Kb, the value for `--extra-space` requires the explicit 'K' suffix (the
default is 'M')
Signed-off-by: Adam Johnston <adam.johnston@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
This is mostly based on the existing qemu-generic-arm64 machine, but by
not being based on the genericarm64 and instead being specifically a
machine to run on the qemu sbsa-ref machine we get to tune differently.
Specifically, this configures sbsa-ref to be a Neoverse N2 (v9), and the
tune is set to match. Another notable difference to qemu-generic-arm64
is that the kernel configuration is at present defconfig. We may wish
to change this in the future to be the same fragmented configuration as
genericarm64.
We have to ignore two testimage parselogs failures: one from NUMA which
will be fixed in a future EDK2 release, and one from efifb where we
should be using the bochsdrm driver instead (further investigation is
needed)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Enable the patch-status warning for meta-arm and meta-arm-bsp.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
corstone1000's uboot uses efitools-native from meta-efi-secure-boot, so
add the layer dependency to make this clear.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
1. Configure FVP base to allow Arm SystemReady IR ACS console access.
2. Configure FVP base Arm SystemReady IR ACS firmware build.
3. Add the machine-specific report.txt for FVP base.
4. Patch the check-sr-results.yaml and format-sr-results.yaml files
to handle the known differences between FVP base and the
expected ACS functionality.
5. Add a README with instructions of how to use the meta-arm-systemready
layer with fvp-base.
Signed-off-by: Debbie Martin <Debbie.Martin@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
oe-core's master branch is diverging from langdale and meta-arm will be
following this, so drop compatibility with langdale in master so we're
free to diverge too.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
As the latest python3-crytography breaks TF-M builds, downgrade those
machines using TF-M (musca and corstone) to python3-crytography-native
3.3.2 temporarily.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
meta-python has upgraded to python3-cryptography 36, which has a problem
when used in native recipes:
cryptography.exceptions.InternalError: Unknown OpenSSL error
This causes all builds of TF-M to fail.
Until this error is fixed, add the old version of python3-cryptography.
A BBMASK is set so that it has to be explicitly opted-in, as it DEPENDS
on recipes from meta-python which isn't a hard dependency for meta-arm.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Until this is integrated into meta-python, hold a copy of
python3-imgtool in meta-arm-bsp used by trusted-firmware-m.
Change-Id: I2e86be503bee03de549f5714dc52921165afa2bf
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Signed-off-by: Arpita S.K <Arpita.S.K@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
No testing is being done against older branches. Only have the
compatibility set to honister to prevent any issues.
Signed-off-by: Jon Mason <jon.mason@arm.com>
We don't test this, and don't expect it to work, so don't claim it does.
Change-Id: I045930e690edba5a5b0b8cb810130c8c6733623f
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Upstream oe-core is preparing to be the Hardknott release, so add
hardknott to our compatible release list.
Once hardknott is public we should remove gatesgarth.
Change-Id: Ia5c59e703910db96a3967a1ecad074ac80d03ee9
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Without exceptional justification there is no good reason for layers to
have a priority other than 5, to match oe-core. If a layer has a
priority higher than oe-core's then recipes in that layer take immediate
preference over those in oe-core and there's no simple way to resolve
this as that is exactly what is meant to happen.
As a concrete example, meta-arm-bsp contains older releases of U-Boot
for platforms that have not yet moved to the latest release in oe-core.
As the priority of meta-arm-bsp is higher, simply adding this layer to a
qemuarm build will immediately downgrade u-boot.
As there is no exceptional justification for the differing priorities,
unify on 5.
Change-Id: I1975753b4a9799cc00310a7c8a6a11c2aef41f65
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Corstone, a5ds, and sgi575 were using the meta-kernel, but recent
updates removed support for their non-LTS kernel. Change to using the
respective kernels present in linux-yocto until it can be upgraded to
the latest version.
Change-Id: I63f2e511fe69051c06e6559950b798c1371cc8e9
Signed-off-by: Jon Mason <jon.mason@arm.com>
Drop dunfell support from the master branch in anticipation of the
gatestgarth release. All dunfell users should reference the dunfell
branch.
Change-Id: I9c5806f698cca42773aaea1fb49e0dfff437eaf4
Signed-off-by: Jon Mason <jon.mason@arm.com>
Layers are only being tested against dunfell and gatesgarth. Limit the
layer compatibility to only those versions.
Change-Id: Ib4df617d8991b1c9096b8feaad9228174319bf11
Signed-off-by: Jon Mason <jon.mason@arm.com>
a5ds is having issues building its stable kernel on master. Migrate to
meta-kernel to fix the build break. This has the benefit of meta-arm
not having a unique stable kernel recipe to maintain and support.
Also, change the name of linux-yocto-arm-platforms to be more
generic, as it doesn't accurately reflect where it is currently being
used and can be used by different kernels going forward.
Change-Id: I4e76c7f1ee4b84641279a389820940fac7130df1
Signed-off-by: Jon Mason <jon.mason@arm.com>
meta-arm-bsp no longer has to depend on meta-oe, and in the future
meta-gem5 could be moved out of meta-arm.
Change-Id: I49fa8f793b60af8c0cdb7e04b27fb53fc094cdad
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Remove all variables, settings and operations specific to Xen from
meta-arm-bsp.
These implementations will be added later in another separate layer.
Change-Id: I971a6898f985f5ec7264da5ad5e4b6436067e3dd
Issue-Id: SCM-769
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
meta-arm-bsp has dependencies on other layers, which are not being
represented in the layers.conf file. This causes build breaks when
using tools like `bitbake-layers layerindex-fetch`, as it will not fetch
the depencies properly. Currently, the dependencies on other layers are:
* core => u-boot, linux, etc
* openembedded-layer (meta-oe) => haveged
* meta-arm => trusted-firmware-a
Change-Id: Icafc2f1c55a6138172706bb4b99e9dc59904cad4
Signed-off-by: Jon Mason <jon.mason@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Add recipes and configuration files to add Yocto support
for Foundation armv8 simulator from arm.
The following components are supported:
- trusted-firmware-a
- linux kernel (with specific kernel configuration)
- xen (with meta-virtualization layer)
- unpacking and starting the generated image directly in Foundation
simulator (package must be download from www.arm.com website and put in
the directory downloads/licensed/silver.arm.com).
After building, the following command can be used to start a generated
image in foundation:
./tmp/deploy/tools/start-foundation-armv8.sh
Change-Id: Iade343c38f0799ee8523434d555cb3ca42068a86
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Michael Safwat
Ross Burton
Jon Mason
Hugues KAMBA MPIANA
Adam Johnston
Khem Raj
Martin Jansa
Debbie Martin
Arpita S.K
Abdellatif El Khlifi
Ross Burton
Kamil Dziezyk
Diego Sueiro
Denys Dmytriyenko
Bertrand Marquis