diff options
author | Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> | 2023-08-04 14:33:40 +0100 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2023-08-08 10:22:03 -0400 |
commit | 39d383bdace4b39b10665c7df2f1ef17399f6f1e (patch) | |
tree | c24057673a660b67e884927e7f5820bad2e45139 /doc/arch | |
parent | b83dc8df6471f472340b88f1e3f3230e836b1fa9 (diff) | |
download | u-boot-39d383bdace4b39b10665c7df2f1ef17399f6f1e.zip u-boot-39d383bdace4b39b10665c7df2f1ef17399f6f1e.tar.gz u-boot-39d383bdace4b39b10665c7df2f1ef17399f6f1e.tar.bz2 |
arm_ffa: introduce Arm FF-A support
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Diffstat (limited to 'doc/arch')
-rw-r--r-- | doc/arch/arm64.ffa.rst | 236 | ||||
-rw-r--r-- | doc/arch/index.rst | 1 |
2 files changed, 237 insertions, 0 deletions
diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst new file mode 100644 index 0000000..df18948 --- /dev/null +++ b/doc/arch/arm64.ffa.rst @@ -0,0 +1,236 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Arm FF-A Support +================ + +Summary +------- + +FF-A stands for Firmware Framework for Arm A-profile processors. + +FF-A specifies interfaces that enable a pair of software execution environments aka partitions to +communicate with each other. A partition could be a VM in the Normal or Secure world, an +application in S-EL0, or a Trusted OS in S-EL1. + +The U-Boot FF-A support (the bus) implements the interfaces to communicate +with partitions in the Secure world aka Secure partitions (SPs). + +The FF-A support specifically focuses on communicating with SPs that +isolate portions of EFI runtime services that must run in a protected +environment which is inaccessible by the Host OS or Hypervisor. +Examples of such services are set/get variables. + +The FF-A support uses the SMC ABIs defined by the FF-A specification to: + +- Discover the presence of SPs of interest +- Access an SP's service through communication protocols + e.g. EFI MM communication protocol + +At this stage of development only EFI boot-time services are supported. +Runtime support will be added in future developments. + +The U-Boot FF-A support provides the following parts: + +- A Uclass driver providing generic FF-A methods. +- An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods. + +FF-A and SMC specifications +------------------------------------------- + +The current implementation of the U-Boot FF-A support relies on +`FF-A v1.0 specification`_ and uses SMC32 calling convention which +means using the first 32-bit data of the Xn registers. + +At this stage we only need the FF-A v1.0 features. + +The FF-A support has been tested with OP-TEE which supports SMC32 calling +convention. + +Hypervisors are supported if they are configured to trap SMC calls. + +The FF-A support uses 64-bit registers as per `SMC Calling Convention v1.2 specification`_. + +Supported hardware +-------------------------------- + +Aarch64 plaforms + +Configuration +---------------------- + +CONFIG_ARM_FFA_TRANSPORT + Enables the FF-A support. Turn this on if you want to use FF-A + communication. + When using an Arm 64-bit platform, the Arm FF-A driver will be used. + +FF-A ABIs under the hood +--------------------------------------- + +Invoking an FF-A ABI involves providing to the secure world/hypervisor the +expected arguments from the ABI. + +On an Arm 64-bit platform, the ABI arguments are stored in x0 to x7 registers. +Then, an SMC instruction is executed. + +At the secure side level or hypervisor the ABI is handled at a higher exception +level and the arguments are read and processed. + +The response is put back through x0 to x7 registers and control is given back +to the U-Boot Arm FF-A driver (non-secure world). + +The driver reads the response and processes it accordingly. + +This methodology applies to all the FF-A ABIs. + +FF-A bus discovery on Arm 64-bit platforms +--------------------------------------------- + +When CONFIG_ARM_FFA_TRANSPORT is enabled, the FF-A bus is considered as +an architecture feature and discovered using ARM_SMCCC_FEATURES mechanism. +This discovery mechanism is performed by the PSCI driver. + +The PSCI driver comes with a PSCI device tree node which is the root node for all +architecture features including FF-A bus. + +:: + + => dm tree + + Class Index Probed Driver Name + ----------------------------------------------------------- + ... + firmware 0 [ + ] psci |-- psci + ffa 0 [ ] arm_ffa | `-- arm_ffa + ... + +The PSCI driver is bound to the PSCI device and when probed it tries to discover +the architecture features by calling a callback the features drivers provide. + +In case of FF-A, the callback is arm_ffa_is_supported() which tries to discover the +FF-A framework by querying the FF-A framework version from secure world using +FFA_VERSION ABI. When discovery is successful, the ARM_SMCCC_FEATURES +mechanism creates a U-Boot device for the FF-A bus and binds the Arm FF-A driver +with the device using device_bind_driver(). + +At this stage the FF-A bus is registered with the DM and can be interacted with using +the DM APIs. + +Clients are able to probe then use the FF-A bus by calling uclass_first_device(). + +When calling uclass_first_device(), the FF-A driver is probed and ends up calling +ffa_do_probe() provided by the Uclass which does the following: + + - saving the FF-A framework version in uc_priv + - querying from secure world the u-boot endpoint ID + - querying from secure world the supported features of FFA_RXTX_MAP + - mapping the RX/TX buffers + - querying from secure world all the partitions information + +When one of the above actions fails, probing fails and the driver stays not active +and can be probed again if needed. + +Requirements for clients +------------------------------------- + +When using the FF-A bus with EFI, clients must query the SPs they are looking for +during EFI boot-time mode using the service UUID. + +The RX/TX buffers are only available at EFI boot-time. Querying partitions is +done at boot time and data is cached for future use. + +RX/TX buffers should be unmapped before EFI runtime mode starts. +The driver provides a bus operation for that called ffa_rxtx_unmap(). + +The user should call ffa_rxtx_unmap() to unmap the RX/TX buffers when required +(e.g: at efi_exit_boot_services()). + +The Linux kernel allocates its own RX/TX buffers. To be able to register these kernel buffers +with secure world, the U-Boot's RX/TX buffers should be unmapped before EFI runtime starts. + +When invoking FF-A direct messaging, clients should specify which ABI protocol +they want to use (32-bit vs 64-bit). Selecting the protocol means using +the 32-bit or 64-bit version of FFA_MSG_SEND_DIRECT_{REQ, RESP}. +The calling convention between U-Boot and the secure world stays the same: SMC32. + +Requirements for user drivers +------------------------------------- + +Users who want to implement their custom FF-A device driver while reusing the FF-A Uclass can do so +by implementing their own invoke_ffa_fn() in the user driver. + +The bus driver layer +------------------------------ + +FF-A support comes on top of the SMCCC layer and is implemented by the FF-A Uclass drivers/firmware/arm-ffa/arm-ffa-uclass.c + +The following features are provided: + +- Support for the 32-bit version of the following ABIs: + + - FFA_VERSION + - FFA_ID_GET + - FFA_FEATURES + - FFA_PARTITION_INFO_GET + - FFA_RXTX_UNMAP + - FFA_RX_RELEASE + - FFA_RUN + - FFA_ERROR + - FFA_SUCCESS + - FFA_INTERRUPT + - FFA_MSG_SEND_DIRECT_REQ + - FFA_MSG_SEND_DIRECT_RESP + +- Support for the 64-bit version of the following ABIs: + + - FFA_RXTX_MAP + - FFA_MSG_SEND_DIRECT_REQ + - FFA_MSG_SEND_DIRECT_RESP + +- Processing the received data from the secure world/hypervisor and caching it + +- Hiding from upper layers the FF-A protocol and registers details. Upper + layers focus on exchanged data, FF-A support takes care of how to transport + that to the secure world/hypervisor using FF-A + +- FF-A support provides driver operations to be used by upper layers: + + - ffa_partition_info_get + - ffa_sync_send_receive + - ffa_rxtx_unmap + +- FF-A bus discovery makes sure FF-A framework is responsive and compatible + with the driver + +- FF-A bus can be compiled and used without EFI + +Example of boot logs with FF-A enabled +-------------------------------------- + +For example, when using FF-A with Corstone-1000 the logs are as follows: + +:: + + U-Boot 2023.01 (May 10 2023 - 11:08:07 +0000) corstone1000 aarch64 + + DRAM: 2 GiB + Arm FF-A framework discovery + FF-A driver 1.0 + FF-A framework 1.0 + FF-A versions are compatible + ... + FF-A driver 1.0 + FF-A framework 1.0 + FF-A versions are compatible + EFI: MM partition ID 0x8003 + ... + EFI stub: Booting Linux Kernel... + ... + Linux version 6.1.9-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-musl-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40.202301193 + Machine model: ARM Corstone1000 FPGA MPS3 board + +Contributors +------------ + * Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> + +.. _`FF-A v1.0 specification`: https://documentation-service.arm.com/static/5fb7e8a6ca04df4095c1d65e +.. _`SMC Calling Convention v1.2 specification`: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 diff --git a/doc/arch/index.rst b/doc/arch/index.rst index b8da4b8..2f916f4 100644 --- a/doc/arch/index.rst +++ b/doc/arch/index.rst @@ -8,6 +8,7 @@ Architecture-specific doc arc arm64 + arm64.ffa m68k mips nios2 |