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>