Harsimran Singh Tungal
5d481fd065
This commit implement the required changes in Trusted-Services in order to incorporate PSA FWU implementation. It involves the following changes: 1. Integrate IPC framework for PSA FWU calls between Cortex-A and Cortex-M subsystems. IPC framework is required to bridge the PSA FWU calls for the platforms which have both Cortex-A and Cortex-M subsystems. Corstone-1000 falls under this category of platforms. In these platforms, the PSA FWU client and PSA FWU provider exist on Cortex-A and all the PSA FWU services are implemented on Cortex-M side. This IPC framework forwards the PSA FWU calls from Cortex-A to Cortex-M subsystem. 2. Load initial image state in PSA FWU M update agent Set initial image state based on the image state returned by psa_fwu_query. This way the update agent has the correct view of images after reboot and it can accept or reject them. 3. Define PSA FWU image mapping structure. Define PSA FWU image mapping structure for Corstone-1000. This structure is responsible to map specific image guid with component number. To enable platform-specific handling, service_proxy_factory.c now conditionally selects the appropriate image mapping based on PLATFORM_IS_FVP. This ensures that both FVP and MPS3 platforms use the correct GUID and firmware update configuration. 4. Fix PSA FWU IPC psa_fwu_install() return value check This change adds support to validate if the return type in psa_fwu_install() is either PSA_SUCCESS or PSA_SUCCESS_REBOOT. Both the return values are expected. Earlier, only PSA_SUCCESS is validated. 5. Add ESRT support Add ESRT support for PSA FWU M agent. ESRT functionality is implemented using unique image dedicated for ESRT data having its own UUID. In PSA FWU M agent's context, this image has read only attributes. The ESRT data can be read using image_read_directory by using ESRT image UUID handle. The ESRT data is queried from Secure Enclave using psa_fwu_query() and ESRT data can be read from psa_fwu_impl_info_t structure object defined in psa_fwu_component_info_t. This commit includes the following changes: 1. Declare ESRT data structures. 2. Modify image_directory_read() to include ESRT data read support 3. Modify psa_fwu_m_update_agent_init to initialize ESRT image attributes 6. Enable ESRT support Enable ESRT support for Corstone-1000. Introduce ESRT image UUID and its component number and set TFM_FWU_MAX_DIGEST_SIZE to ESRT data size. 7. Add event provider proxy Normal world needs to send boot confirmation event to Secure Enclave and Trusted-Services is responsible to transfer the event to Secure Enclave. This commit implements the event handling framework in SE-proxy-SP and develops event provider proxy which forwards the event to Secure Enclave via psa calls. This change is introduced for Corstone-1000 8. Define GUID for each payloads Define GUID's for all the 4 payloads for FVP and MPS3. Signed-off-by: Harsimran Singh Tungal <harsimransingh.tungal@arm.com> Signed-off-by: Ali Can Ozaslan <ali.oezaslan@arm.com> Signed-off-by: Imre Kis <imre.kis@arm.com> Signed-off-by: Jon Mason <jon.mason@arm.com>
Introduction
This repository contains the Arm layers for OpenEmbedded.
-
meta-arm
This layer contains general recipes for the Arm architecture, such as firmware, FVPs, and Arm-specific integration.
-
meta-arm-bsp
This layer contains machines for Arm reference platforms, for example FVP Base, Corstone1000, and Juno.
-
meta-arm-toolchain
This layer contains recipes for Arm's binary toolchains (GCC and Clang for -A and -M), and a recipe to build Arm's GCC.
Other Directories
-
ci
This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this.
-
documentation
This directory contains information on the files in this repository, building, and other relevant documents.
-
kas
This directory contains KAS yaml files to describe builds for systems not used in CI.
-
scripts
This directory contains scripts used in running the CI tests.
Mailing List
To interact with the meta-arm developer community, please email the meta-arm mailing list at meta-arm@lists.yoctoproject.org. Currently, it is configured to only allow emails to members from those subscribed. To subscribe to the meta-arm mailing list, please go to https://lists.yoctoproject.org/g/meta-arm
Contributing
Currently, we only accept patches from the meta-arm mailing list. For general information on how to submit a patch, please read https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org
Commits and patches added should follow the OpenEmbedded patch guidelines:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
arm-bsp/trusted-firmware-a: decrease frobbing level
arm-toolchain/gcc: enable foobar v2
All contributions are under the MIT License.
For a quick start guide on how to build and use meta-arm, go to quick-start.md.
For information on the continuous integration done on meta-arm and how to use it, go to continuous-integration-and-kas.md.
Backporting
Backporting patches to older releases may be done upon request, but only after a version of the patch has been accepted into the master branch. This is done by adding the branch name to email subject line. This should be between the square brackets (e.g., "[" and "]"), and before or after the "PATCH". For example,
[nanbield PATCH] arm/linux-yocto: backport patch to fix 6.5.13 networking issues
Automatic backporting will be done to all branches if the "Fixes: " wording is added to the patch commit message. This is similar to how the Linux kernel community does their LTS kernel backporting. For more information see the "Fixes" portion of https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
Releases and Release Schedule
We follow the Yocto Project release methodology, schedule, and stable/LTS support timelines. For more information on these, please reference:
- https://docs.yoctoproject.org/ref-manual/release-process.html
- https://wiki.yoctoproject.org/wiki/Releases
- https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
For more in-depth information on the meta-arm release and branch methodology, go to </documentation/releases.md>.
Reporting bugs
E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps to reproduce the issue.
Security and Reporting Security Issues
For information on the security of meta-arm and how to report issues, please consult SECURITY.md.
Maintainer(s)
- Jon Mason jon.mason@arm.com
- Ross Burton ross.burton@arm.com