1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
.. 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
|
