| .. 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. |
| - A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides |
| FF-A ABIs inspection methods. |
| - An FF-A sandbox device driver for FF-A communication with the emulated Secure World. |
| The driver leverages the FF-A Uclass to establish FF-A communication. |
| - Sandbox FF-A test cases. |
| |
| 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. |
| When using sandbox, the sandbox FF-A emulator and FF-A sandbox 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(). |
| Please refer to the armffa command implementation as an example of how to probe |
| and interact with the FF-A bus. |
| |
| 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 |
| |
| Relationship between the sandbox emulator and the FF-A device |
| --------------------------------------------------------------- |
| |
| :: |
| |
| => dm tree |
| |
| Class Index Probed Driver Name |
| ----------------------------------------------------------- |
| ffa_emul 0 [ + ] sandbox_ffa_emul `-- arm-ffa-emul |
| ffa 0 [ ] sandbox_arm_ffa `-- sandbox-arm-ffa |
| |
| The armffa command |
| ----------------------------------- |
| |
| armffa is a command showcasing how to use the FF-A bus and how to invoke the driver operations. |
| |
| Please refer the command documentation at :doc:`../usage/cmd/armffa` |
| |
| Example of boot logs with FF-A enabled |
| -------------------------------------- |
| |
| For example, when using FF-A with Corstone-1000, debug logs enabled, the output is 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 |