xref: /rk3399_ARM-atf/docs/components/ffa-manifest-binding.rst (revision aea8f36ccb999395ee8c47f4e8dc2363ac164953)
1FF-A manifests binding to device tree
2=====================================
3
4This document defines the nodes and properties used to define a partition,
5according to the FF-A specification, and the SPMC manifest.
6
7FF-A Partition Manifest Properties
8----------------------------------
9
10The FF-A partition manifest is consumed by the SPMC to configure the state
11associated with the related Secure Partition.
12
13- compatible [mandatory]
14   - value type: <string>
15   - Must be the string "arm,ffa-manifest-X.Y" which specifies the major and
16     minor versions of the device tree binding for the FFA manifest represented
17     by this node. The minor number is incremented if the binding changes in a
18     backwards compatible manner.
19
20      - X is an integer representing the major version number of this document.
21      - Y is an integer representing the minor version number of this document.
22
23- ffa-version [mandatory]
24   - value type: <u32>
25   - Must be two 16 bits values (X, Y), concatenated as 31:16 -> X,
26     15:0 -> Y, where:
27
28      - X is the major version of FF-A expected by the partition at the FFA
29        instance it will execute.
30      - Y is the minor version of FF-A expected by the partition at the FFA
31        instance it will execute.
32
33- id
34   - value type: <u32>
35   - Pre-allocated partition ID.
36
37- auxiliary-id
38   - value type: <u32>
39   - Pre-allocated ID that could be used in memory management transactions.
40
41- description
42   - value type: <string>
43   - Name of the partition e.g. for debugging purposes.
44
45- execution-ctx-count [mandatory]
46   - value type: <u32>
47   - Number of vCPUs that a VM or SP wants to instantiate.
48
49      - In the absence of virtualization, this is the number of execution
50        contexts that a partition implements.
51      - If value of this field = 1 and number of PEs > 1 then the partition is
52        treated as UP & migrate capable.
53      - If the value of this field > 1 then the partition is treated as a MP
54        capable partition irrespective of the number of PEs.
55
56- exception-level [mandatory]
57   - value type: <u32>
58   - The target exception level for the partition:
59
60      - 0x0: EL1
61      - 0x1: S_EL0
62      - 0x2: S_EL1
63
64- execution-state [mandatory]
65   - value type: <u32>
66   - The target execution state of the partition:
67
68      - 0: AArch64
69      - 1: AArch32
70
71- load-address
72   - value type: <u64>
73   - Physical base address of the partition in memory. Absence of this field
74     indicates that the partition is position independent and can be loaded at
75     any address chosen at boot time.
76
77- entrypoint-offset
78   - value type: <u64>
79   - Offset from the base of the partition's binary image to the entry point of
80     the partition. Absence of this field indicates that the entry point is at
81     offset 0x0 from the base of the partition's binary.
82
83- xlat-granule
84   - value type: <u32>
85   - Translation granule used with the partition:
86
87      - 0x0: 4k
88      - 0x1: 16k
89      - 0x2: 64k
90
91- boot-order
92   - value type: <u32>
93   - A unique number amongst all partitions that specifies if this partition
94     must be booted before others. The partition with the smaller number will be
95     booted first. Highest vlue allowed for this field is 0xFFFF.
96
97- rx-tx-buffer
98   - value type: "memory-regions" node
99   - Specific "memory-regions" nodes that describe the RX/TX buffers expected
100     by the partition.
101     The "compatible" must be the string "arm,ffa-manifest-rx_tx-buffer".
102
103- managed-exit
104   - value type: <empty>
105   - Specifies if managed exit is supported.
106   - This field is deprecated in favor of ns-interrupts-action field in the FF-A
107     v1.1 EAC0 spec.
108
109- managed-exit-virq
110   - value type: <empty>
111   - Indicates if the partition needs managed exit, if supported, to be signaled
112     through vIRQ signal.
113
114- ns-interrupts-action [mandatory]
115   - value type: <u32>
116   - Specifies the action that the SPMC must take in response to a Non-secure
117     physical interrupt.
118
119      - 0x0: Non-secure interrupt is queued
120      - 0x1: Non-secure interrupt is signaled after a managed exit
121      - 0x2: Non-secure interrupt is signaled
122
123   - This field supersedes the managed-exit field in the FF-A v1.0 spec.
124
125- other-s-interrupts-action
126   - value type: <u32>
127   - Specifies the action that the SPMC must take in response to a Other-Secure
128     physical interrupt.
129
130      - 0x0: Other-Secure interrupt is queued
131      - 0x1: Other-Secure interrupt is signaled
132
133- sri-interrupts-policy
134
135  - value type: <u32>
136  - Specifies how secure interrupts are handled when the SP is in a waiting
137    state and is targeted by a secure interrupt, or when the SP attempts to
138    return to a waiting state with pending secure interrupts. The value is a
139    bitfield.
140
141      - 0x0: Proactively inject the VI and resume SP when handling a secure
142        interrupt and SP in the waiting state.
143      - 0x1: Only when a secure interrupt is fired while target SP in the
144        waiting state, pend SRI to the NWd and rely on the scheduler to
145        explicitly donate CPU cycles to the SP.
146      - 0x2: Only when the SP attempts to go back to the waiting state while
147        having pending secure interrupts, trigger the SRI to the NWd and rely
148        on the scheduler to explicitly donate CPU cycles to the SP.
149      - 0x3: Enable both actions for values 0x1 and 0x2.
150
151- has-primary-scheduler
152   - value type: <empty>
153   - Presence of this field indicates that the partition implements the primary
154     scheduler. If so, run-time EL must be EL1.
155
156- time-slice-mem
157   - value type: <empty>
158   - Presence of this field indicates that the partition doesn't expect the
159     partition manager to time slice long running memory management functions.
160
161- gp-register-num
162   - value type: <u32>
163   - The field specifies the general purpose register number but not its width.
164     The width is derived from the partition's execution state, as specified in
165     the partition properties. For example, if the number value is 1 then the
166     general-purpose register used will be x1 in AArch64 state and w1 in AArch32
167     state.
168     Presence of this field indicates that the partition expects the address of
169     the FF-A boot information blob to be passed in the specified general purpose
170     register.
171
172- power-management-messages
173   - value type: <u32>
174   - Specifies which power management messages a partition subscribes to.
175     A set bit means the partition should be informed of the power event, clear
176     bit - should not be informed of event:
177
178      - Bit[0]: CPU_OFF
179      - Bit[1]: CPU_SUSPEND
180      - Bit[2]: CPU_SUSPEND_RESUME
181
182- vm-availability-messages
183   - value type: <u32>
184   - Specifies which VM availability messages a partition subscribes to. A set
185     bit means the partition should be informed of the event, clear bit - should
186     not be informed of event:
187
188      - Bit[0]: VM created
189      - Bit[1]: VM destroyed
190
191- lifecycle-support
192   - value type: <empty>
193   - Presence of this field indicates support for all partition lifecycle states
194     defined in the FF-A v1.3 ALP2 spec.
195
196- abort-action
197   - value type: <u32>
198   - Specifies the action that the SPMC takes when a partition encounters a fatal
199     error.
200
201      - 0x0: STOP
202      - 0x1: DESTROY
203      - 0x2: RESTART
204      - 0x3: PROPAGATE
205
206   - All other values are unsupported. If a partition does not specify this
207     field in the manifest, the SPMC takes implementation defined action.
208
209- live-activation-support
210   - value type: <empty>
211   - Presence of this field indicates support for partition framework messages
212     necessary for live activation as defined in the FF-A v1.3 ALP2 spec.
213
214- live-activation-register
215   - value type: <u32>
216   - Register used by the SPMC to report to the SP that it is undergoing live
217     activation. Must be one of ``x0``–``x3`` or ``x5``–``x7`` so that it does
218     not clash with the boot-info register or the reserved ``x4`` linear vCPU
219     index.
220
221- image-uuid
222   - value type: <prop-encoded-array>
223   - Exactly one tuple of 4 <u32> values identifying the partition image UUID.
224     The UUID must not be all zeros and must not collide with any protocol UUID
225     exposed by the partition.
226
227- live-state-buffer-info
228   - value type: <phandle>
229   - Child node with ``compatible = "arm,ffa-manifest,live-state-buffer"`` whose
230     ``live-state-buffer`` property points to the backing memory-region entry.
231
232When ``live-activation-support`` is present the manifest must also meet the
233following requirements:
234
235- ``lifecycle-support`` must be present and ``execution-ctx-count`` must be 1.
236- ``live-activation-register`` and ``image-uuid`` must follow the constraints
237  above; manifests advertising multiple image UUIDs or invalid registers are
238  rejected.
239- The live state buffer referenced via ``live-state-buffer-info`` must be
240  defined under ``memory-regions`` and describe a page-aligned, read/write
241  region that sits outside the working memory region (which is overwritten
242  during activation) and is large enough to preserve the framework state.
243
244Informative example:
245
246.. code:: dts
247
248   lifecycle-support;
249   execution-ctx-count = <1>;
250   abort-action = <1>;
251   live-activation-support;
252   live-activation-register = <1>;
253   image-uuid = <0x962a7bf0 0x174d471d 0xa686c89e 0x5c3e254e>;
254
255   live-state-buffer-info {
256       compatible = "arm,ffa-manifest,live-state-buffer";
257       live-state-buffer = <&livestatebuffer>;
258   };
259
260   memory-regions {
261       compatible = "arm,ffa-manifest-memory-regions";
262
263       livestatebuffer: live-state-buffer {
264           description = "live-state-buffer";
265           base-address = <0x00000000 0x06780000>;
266           pages-count = <1>;
267           attributes = <0x3>; /* read-write */
268       };
269   };
270
271.. _services:
272
273Services
274~~~~~~~~
275
276- A service pairs a protocol UUID with supported messaging methods that clients
277  use to reach the SP.
278- For the compatible value at the root set to "arm,ffa-manifest-1.0", the UUIDs
279  and messaging methods are specified in two separate lists at the root node as
280  below:
281
282   - uuid [mandatory]
283      - value type: <prop-encoded-array>
284      - An array of comma separated tuples each consisting of 4 <u32> values,
285        identifying the protocol UUIDs of the services implemented by this
286        partition. The UUID format is described in RFC 4122.
287      - These 4 <u32> values are packed similar to the UUID register mapping
288        specified in section '5.3 Unique Identification format',
289        SMC Calling Convention, DEN0028, v1.6 G BET0
290        (https://developer.arm.com/documentation/den0028/latest/).
291   - messaging-method [mandatory]
292      - value type: <prop-encoded-array>
293      - An array of <u32> values which specify which messaging methods are
294        supported for each service. If one value is specified all services
295        support those messaging methods. If multiple values are specified, there
296        must be the same number as UUIDs specified, and the messaging method at
297        each index is paired with the UUID at the matching index of the uuid
298        array. Set bit means the feature is supported, clear bit - not supported:
299
300         - Bit[0]: partition can receive direct requests via
301           FFA_MSG_SEND_DIRECT_REQ ABI if set
302         - Bit[1]: partition can send direct requests via
303           FFA_MSG_SEND_DIRECT_REQ ABI if set
304         - Bit[2]: partition can send and receive indirect messages
305         - Bit[9]: partition can receive direct requests via
306           FFA_MSG_SEND_DIRECT_REQ2 ABI if set
307         - Bit[10]: partition can send direct requests via
308           FFA_MSG_SEND_DIRECT_REQ2 ABI if set
309      - A request targeting a specific protocol UUID requires that service to
310        have the corresponding bit set. Requests that do not target a specific
311        protocol UUID (for example, a NULL UUID or FFA_MSG_SEND_DIRECT_REQ) are
312        allowed if any service exposes the required messaging method.
313
314- For compatible value "arm,ffa-manifest-X.Y" with X.Y > 1.0, specify services
315  under a parent "services" node like so:
316
317   - services [mandatory]
318      - compatible [mandatory]
319         - value type: <string>
320         - Must be the string "arm,ffa-manifest-services".
321      - Child service nodes [mandatory]
322         - uuid [mandatory]
323            - value type: <string>
324            - A protocol UUID specified in the canonical string format as
325              described in RFC 9562.
326              (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-format)
327         - messaging-method [mandatory]
328            - value type: <u32>
329            - Specifies which messaging methods are supported by this service,
330              set bit means the feature is supported, clear bit - not supported:
331
332               - Bit[0]: partition can receive direct requests via
333                 FFA_MSG_SEND_DIRECT_REQ ABI if set
334               - Bit[1]: partition can send direct requests via
335                 FFA_MSG_SEND_DIRECT_REQ ABI if set
336               - Bit[2]: partition can send and receive indirect messages
337               - Bit[9]: partition can receive direct requests via
338                 FFA_MSG_SEND_DIRECT_REQ2 ABI if set
339               - Bit[10]: partition can send direct requests via
340                 FFA_MSG_SEND_DIRECT_REQ2 ABI if set
341         - Each child under "services" pairs a protocol UUID with a messaging
342           method. At least one child must be specified.
343         - A request targeting a specific protocol UUID requires that service to
344           have the corresponding bit set. Requests that do not target a specific
345           protocol UUID (for example, a NULL UUID or FFA_MSG_SEND_DIRECT_REQ) are
346           allowed if any service exposes the required messaging method.
347
348.. _memory_region_node:
349
350Memory Regions
351~~~~~~~~~~~~~~
352
353- compatible [mandatory]
354   - value type: <string>
355   - Must be the string "arm,ffa-manifest-memory-regions".
356
357- description
358   - value type: <string>
359   - Name of the memory region e.g. for debugging purposes.
360
361- pages-count [mandatory]
362   - value type: <u32>
363   - Count of pages of memory region as a multiple of the translation granule
364     size
365
366- attributes [mandatory]
367   - value type: <u32>
368   - Mapping modes: ORed to get required permission
369
370      - 0x1: Read
371      - 0x2: Write
372      - 0x4: Execute
373      - 0x8: Security state
374
375- base-address
376   - value type: <u64>
377   - Base address of the region. The address must be aligned to the translation
378     granule size.
379     The address given may be a Physical Address (PA), Virtual Address (VA), or
380     Intermediate Physical Address (IPA). Refer to the FF-A specification for
381     more information on the restrictions around the address type.
382     If the base address is omitted then the partition manager must map a memory
383     region of the specified size into the partition's translation regime and
384     then communicate the region properties (including the base address chosen
385     by the partition manager) to the partition.
386
387- load-address-relative-offset
388   - value type: <u64>
389   - Offset relative to the load address of the partition.
390     When this is provided in the partition manifest, it should be added to the
391     load address to get the base address of the region. The secure partition
392     manifest can have either "base-address" or "load-address-relative-offset".
393     It cannot have both.
394
395- stream-ids
396   - value type: <prop-encoded-array>
397   - List of IDs belonging to a DMA capable peripheral device that has access to
398     the memory region represented by current node.
399   - Each ID must have been declared in exactly one device region node.
400
401- smmu-id
402   - value type: <u32>
403   - Identifies the SMMU IP that enforces the access control for the DMA device
404     that owns the above stream-ids.
405
406- stream-ids-access-permissions
407   - value type: <prop-encoded-array>
408   - List of attributes representing the instruction and data access permissions
409     used by the DMA device streams to access the memory region represented by
410     current node.
411
412.. _device_region_node:
413
414Device Regions
415~~~~~~~~~~~~~~
416
417- compatible [mandatory]
418   - value type: <string>
419   - Must be the string "arm,ffa-manifest-device-regions".
420
421- description
422   - value type: <string>
423   - Name of the device region e.g. for debugging purposes.
424
425- pages-count [mandatory]
426   - value type: <u32>
427   - Count of pages of memory region as a multiple of the translation granule
428     size
429
430- attributes [mandatory]
431   - value type: <u32>
432   - Mapping modes: ORed to get required permission
433
434     - 0x1: Read
435     - 0x2: Write
436     - 0x4: Execute
437     - 0x8: Security state
438
439- base-address [mandatory]
440   - value type: <u64>
441   - Base address of the region. The address must be aligned to the translation
442     granule size.
443     The address given may be a Physical Address (PA), Virtual Address (VA), or
444     Intermediate Physical Address (IPA). Refer to the FF-A specification for
445     more information on the restrictions around the address type.
446
447- smmu-id
448   - value type: <u32>
449   - On systems with multiple System Memory Management Units (SMMUs) this
450     identifier is used to inform the partition manager which SMMU the device is
451     upstream of. If the field is omitted then it is assumed that the device is
452     not upstream of any SMMU.
453
454- stream-ids
455   - value type: <prop-encoded-array>
456   - List of IDs where an ID is a unique <u32> value amongst all devices assigned
457     to the partition.
458
459- interrupts
460   - value type: <prop-encoded-array>
461   - A list of (id, attributes) pair describing the device interrupts, where:
462
463      - id: The <u32> interrupt IDs.
464      - attributes: A <u32> value, containing attributes for each interrupt ID:
465
466        +----------------------+----------+
467        |Field                 | Bit(s)   |
468        +----------------------+----------+
469        | Priority	       | 7:0      |
470        +----------------------+----------+
471        | Security state       | 8        |
472        +----------------------+----------+
473        | Config(Edge/Level)   | 9        |
474        +----------------------+----------+
475        | Type(SPI/PPI/SGI)    | 11:10    |
476        +----------------------+----------+
477
478        Security state:
479          - Secure:       1
480          - Non-secure:   0
481
482        Configuration:
483          - Edge triggered:       0
484          - Level triggered:      1
485
486        Type:
487          - SPI:  0b10
488          - PPI:  0b01
489          - SGI:  0b00
490
491- interrupts-target
492   - value type: <prop-encoded-array>
493   - A list of (id, mpdir upper bits, mpidr lower bits) tuples describing which
494     mpidr the interrupt is routed to, where:
495
496      - id: The <u32> interrupt ID. Must be one of those specified in the
497            "interrupts" field.
498      - mpidr upper bits: The <u32> describing the upper bits of the 64 bits
499                          mpidr
500      - mpidr lower bits: The <u32> describing the lower bits of the 64 bits
501                          mpidr
502
503- exclusive-access
504   - value type: <empty>
505   - Presence of this field implies that this endpoint must be granted exclusive
506     access and ownership of this device's MMIO region.
507
508SPMC Manifest Properties
509------------------------
510
511This manifest contains the SPMC *attribute* node consumed by the SPMD at
512boot time.
513
514attribute
515~~~~~~~~~
516
517- spmc_id
518   - value type: <u32>
519   - Defines the endpoint ID value that SPMC can query through ``FFA_ID_GET``.
520- maj_ver
521   - value type: <u32>
522   - Major of the FF-A version implemented by the SPMC. SPMD checks against its own
523     version.
524- min_ver
525   - value type>: <u32>
526   - Minor of the FF-A version implemented by the SPMC. SPMD checks against its own
527     version.
528- exec_state
529   - value type: <u32>
530   - Defines the SPMC execution state (AArch64 or AArch32).
531- load_address
532   - value type: <u64>
533   - Base physical address in which the SPMC binary is placed. Should be page aligned.
534- entrypoint:
535   - value type: <u64>
536   - Defines the physical address for the cold boot primary core entrypoint used by the SPMD
537     (currently matches ``BL32_BASE``) to enter the SPMC.
538- binary_size
539   - value type: <u32>
540   - Defines the maximum size of the SPMC binary. It is used with load_address to sanitize the
541     specified entrypoint.
542
543--------------
544
545*Copyright (c) 2019-2026, Arm Limited and Contributors. All rights reserved.*
546