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 armffa command
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>