blob: 1667ccec8ef7fb24608bb15e06a3b8a3fa9b1a59 [file] [log] [blame]
Dan Handley610e7e12018-03-01 18:44:00 +00001Trusted Firmware-A Porting Guide
2================================
Douglas Raillardd7c21b72017-06-28 15:23:03 +01003
4
5.. section-numbering::
6 :suffix: .
7
8.. contents::
9
10--------------
11
12Introduction
13------------
14
Dan Handley610e7e12018-03-01 18:44:00 +000015Porting Trusted Firmware-A (TF-A) to a new platform involves making some
Douglas Raillardd7c21b72017-06-28 15:23:03 +010016mandatory and optional modifications for both the cold and warm boot paths.
17Modifications consist of:
18
19- Implementing a platform-specific function or variable,
20- Setting up the execution context in a certain way, or
21- Defining certain constants (for example #defines).
22
23The platform-specific functions and variables are declared in
24`include/plat/common/platform.h`_. The firmware provides a default implementation
25of variables and functions to fulfill the optional requirements. These
26implementations are all weakly defined; they are provided to ease the porting
27effort. Each platform port can override them with its own implementation if the
28default implementation is inadequate.
29
Dan Handley610e7e12018-03-01 18:44:00 +000030Platform ports that want to be aligned with standard Arm platforms (for example
Douglas Raillardd7c21b72017-06-28 15:23:03 +010031FVP and Juno) may also use `include/plat/arm/common/plat\_arm.h`_ and the
32corresponding source files in ``plat/arm/common/``. These provide standard
33implementations for some of the required platform porting functions. However,
34using these functions requires the platform port to implement additional
Dan Handley610e7e12018-03-01 18:44:00 +000035Arm standard platform porting functions. These additional functions are not
Douglas Raillardd7c21b72017-06-28 15:23:03 +010036documented here.
37
38Some modifications are common to all Boot Loader (BL) stages. Section 2
39discusses these in detail. The subsequent sections discuss the remaining
40modifications for each BL stage in detail.
41
Dan Handley610e7e12018-03-01 18:44:00 +000042This document should be read in conjunction with the TF-A `User Guide`_.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010043
Soby Mathew02bdbb92018-09-26 11:17:23 +010044Please refer to the `Platform compatibility policy`_ for the policy regarding
45compatibility and deprecation of these porting interfaces.
46
Douglas Raillardd7c21b72017-06-28 15:23:03 +010047Common modifications
48--------------------
49
50This section covers the modifications that should be made by the platform for
51each BL stage to correctly port the firmware stack. They are categorized as
52either mandatory or optional.
53
54Common mandatory modifications
55------------------------------
56
57A platform port must enable the Memory Management Unit (MMU) as well as the
58instruction and data caches for each BL stage. Setting up the translation
59tables is the responsibility of the platform port because memory maps differ
60across platforms. A memory translation library (see ``lib/xlat_tables/``) is
Sandrine Bailleux1861b7a2017-07-20 16:11:01 +010061provided to help in this setup.
62
63Note that although this library supports non-identity mappings, this is intended
64only for re-mapping peripheral physical addresses and allows platforms with high
65I/O addresses to reduce their virtual address space. All other addresses
66corresponding to code and data must currently use an identity mapping.
67
Dan Handley610e7e12018-03-01 18:44:00 +000068Also, the only translation granule size supported in TF-A is 4KB, as various
69parts of the code assume that is the case. It is not possible to switch to
7016 KB or 64 KB granule sizes at the moment.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010071
Dan Handley610e7e12018-03-01 18:44:00 +000072In Arm standard platforms, each BL stage configures the MMU in the
Douglas Raillardd7c21b72017-06-28 15:23:03 +010073platform-specific architecture setup function, ``blX_plat_arch_setup()``, and uses
74an identity mapping for all addresses.
75
76If the build option ``USE_COHERENT_MEM`` is enabled, each platform can allocate a
77block of identity mapped secure memory with Device-nGnRE attributes aligned to
78page boundary (4K) for each BL stage. All sections which allocate coherent
79memory are grouped under ``coherent_ram``. For ex: Bakery locks are placed in a
80section identified by name ``bakery_lock`` inside ``coherent_ram`` so that its
81possible for the firmware to place variables in it using the following C code
82directive:
83
84::
85
86 __section("bakery_lock")
87
88Or alternatively the following assembler code directive:
89
90::
91
92 .section bakery_lock
93
94The ``coherent_ram`` section is a sum of all sections like ``bakery_lock`` which are
95used to allocate any data structures that are accessed both when a CPU is
96executing with its MMU and caches enabled, and when it's running with its MMU
97and caches disabled. Examples are given below.
98
99The following variables, functions and constants must be defined by the platform
100for the firmware to work correctly.
101
102File : platform\_def.h [mandatory]
103~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
104
105Each platform must ensure that a header file of this name is in the system
106include path with the following constants defined. This may require updating the
Dan Handley610e7e12018-03-01 18:44:00 +0000107list of ``PLAT_INCLUDES`` in the ``platform.mk`` file. In the Arm development
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100108platforms, this file is found in ``plat/arm/board/<plat_name>/include/``.
109
110Platform ports may optionally use the file `include/plat/common/common\_def.h`_,
111which provides typical values for some of the constants below. These values are
112likely to be suitable for all platform ports.
113
Dan Handley610e7e12018-03-01 18:44:00 +0000114Platform ports that want to be aligned with standard Arm platforms (for example
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100115FVP and Juno) may also use `include/plat/arm/common/arm\_def.h`_, which provides
116standard values for some of the constants below. However, this requires the
117platform port to define additional platform porting constants in
118``platform_def.h``. These additional constants are not documented here.
119
120- **#define : PLATFORM\_LINKER\_FORMAT**
121
122 Defines the linker format used by the platform, for example
123 ``elf64-littleaarch64``.
124
125- **#define : PLATFORM\_LINKER\_ARCH**
126
127 Defines the processor architecture for the linker by the platform, for
128 example ``aarch64``.
129
130- **#define : PLATFORM\_STACK\_SIZE**
131
132 Defines the normal stack memory available to each CPU. This constant is used
133 by `plat/common/aarch64/platform\_mp\_stack.S`_ and
134 `plat/common/aarch64/platform\_up\_stack.S`_.
135
136- **define : CACHE\_WRITEBACK\_GRANULE**
137
138 Defines the size in bits of the largest cache line across all the cache
139 levels in the platform.
140
141- **#define : FIRMWARE\_WELCOME\_STR**
142
143 Defines the character string printed by BL1 upon entry into the ``bl1_main()``
144 function.
145
146- **#define : PLATFORM\_CORE\_COUNT**
147
148 Defines the total number of CPUs implemented by the platform across all
149 clusters in the system.
150
151- **#define : PLAT\_NUM\_PWR\_DOMAINS**
152
153 Defines the total number of nodes in the power domain topology
154 tree at all the power domain levels used by the platform.
155 This macro is used by the PSCI implementation to allocate
156 data structures to represent power domain topology.
157
158- **#define : PLAT\_MAX\_PWR\_LVL**
159
160 Defines the maximum power domain level that the power management operations
161 should apply to. More often, but not always, the power domain level
162 corresponds to affinity level. This macro allows the PSCI implementation
163 to know the highest power domain level that it should consider for power
164 management operations in the system that the platform implements. For
165 example, the Base AEM FVP implements two clusters with a configurable
166 number of CPUs and it reports the maximum power domain level as 1.
167
168- **#define : PLAT\_MAX\_OFF\_STATE**
169
170 Defines the local power state corresponding to the deepest power down
171 possible at every power domain level in the platform. The local power
172 states for each level may be sparsely allocated between 0 and this value
173 with 0 being reserved for the RUN state. The PSCI implementation uses this
174 value to initialize the local power states of the power domain nodes and
175 to specify the requested power state for a PSCI\_CPU\_OFF call.
176
177- **#define : PLAT\_MAX\_RET\_STATE**
178
179 Defines the local power state corresponding to the deepest retention state
180 possible at every power domain level in the platform. This macro should be
181 a value less than PLAT\_MAX\_OFF\_STATE and greater than 0. It is used by the
182 PSCI implementation to distinguish between retention and power down local
183 power states within PSCI\_CPU\_SUSPEND call.
184
185- **#define : PLAT\_MAX\_PWR\_LVL\_STATES**
186
187 Defines the maximum number of local power states per power domain level
188 that the platform supports. The default value of this macro is 2 since
189 most platforms just support a maximum of two local power states at each
190 power domain level (power-down and retention). If the platform needs to
191 account for more local power states, then it must redefine this macro.
192
193 Currently, this macro is used by the Generic PSCI implementation to size
194 the array used for PSCI\_STAT\_COUNT/RESIDENCY accounting.
195
196- **#define : BL1\_RO\_BASE**
197
198 Defines the base address in secure ROM where BL1 originally lives. Must be
199 aligned on a page-size boundary.
200
201- **#define : BL1\_RO\_LIMIT**
202
203 Defines the maximum address in secure ROM that BL1's actual content (i.e.
204 excluding any data section allocated at runtime) can occupy.
205
206- **#define : BL1\_RW\_BASE**
207
208 Defines the base address in secure RAM where BL1's read-write data will live
209 at runtime. Must be aligned on a page-size boundary.
210
211- **#define : BL1\_RW\_LIMIT**
212
213 Defines the maximum address in secure RAM that BL1's read-write data can
214 occupy at runtime.
215
216- **#define : BL2\_BASE**
217
218 Defines the base address in secure RAM where BL1 loads the BL2 binary image.
Jiafei Pan43a7bf42018-03-21 07:20:09 +0000219 Must be aligned on a page-size boundary. This constant is not applicable
220 when BL2_IN_XIP_MEM is set to '1'.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100221
222- **#define : BL2\_LIMIT**
223
224 Defines the maximum address in secure RAM that the BL2 image can occupy.
Jiafei Pan43a7bf42018-03-21 07:20:09 +0000225 This constant is not applicable when BL2_IN_XIP_MEM is set to '1'.
226
227- **#define : BL2\_RO\_BASE**
228
229 Defines the base address in secure XIP memory where BL2 RO section originally
230 lives. Must be aligned on a page-size boundary. This constant is only needed
231 when BL2_IN_XIP_MEM is set to '1'.
232
233- **#define : BL2\_RO\_LIMIT**
234
235 Defines the maximum address in secure XIP memory that BL2's actual content
236 (i.e. excluding any data section allocated at runtime) can occupy. This
237 constant is only needed when BL2_IN_XIP_MEM is set to '1'.
238
239- **#define : BL2\_RW\_BASE**
240
241 Defines the base address in secure RAM where BL2's read-write data will live
242 at runtime. Must be aligned on a page-size boundary. This constant is only
243 needed when BL2_IN_XIP_MEM is set to '1'.
244
245- **#define : BL2\_RW\_LIMIT**
246
247 Defines the maximum address in secure RAM that BL2's read-write data can
248 occupy at runtime. This constant is only needed when BL2_IN_XIP_MEM is set
249 to '1'.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100250
251- **#define : BL31\_BASE**
252
253 Defines the base address in secure RAM where BL2 loads the BL31 binary
254 image. Must be aligned on a page-size boundary.
255
256- **#define : BL31\_LIMIT**
257
258 Defines the maximum address in secure RAM that the BL31 image can occupy.
259
260For every image, the platform must define individual identifiers that will be
261used by BL1 or BL2 to load the corresponding image into memory from non-volatile
262storage. For the sake of performance, integer numbers will be used as
263identifiers. The platform will use those identifiers to return the relevant
264information about the image to be loaded (file handler, load address,
265authentication information, etc.). The following image identifiers are
266mandatory:
267
268- **#define : BL2\_IMAGE\_ID**
269
270 BL2 image identifier, used by BL1 to load BL2.
271
272- **#define : BL31\_IMAGE\_ID**
273
274 BL31 image identifier, used by BL2 to load BL31.
275
276- **#define : BL33\_IMAGE\_ID**
277
278 BL33 image identifier, used by BL2 to load BL33.
279
280If Trusted Board Boot is enabled, the following certificate identifiers must
281also be defined:
282
283- **#define : TRUSTED\_BOOT\_FW\_CERT\_ID**
284
285 BL2 content certificate identifier, used by BL1 to load the BL2 content
286 certificate.
287
288- **#define : TRUSTED\_KEY\_CERT\_ID**
289
290 Trusted key certificate identifier, used by BL2 to load the trusted key
291 certificate.
292
293- **#define : SOC\_FW\_KEY\_CERT\_ID**
294
295 BL31 key certificate identifier, used by BL2 to load the BL31 key
296 certificate.
297
298- **#define : SOC\_FW\_CONTENT\_CERT\_ID**
299
300 BL31 content certificate identifier, used by BL2 to load the BL31 content
301 certificate.
302
303- **#define : NON\_TRUSTED\_FW\_KEY\_CERT\_ID**
304
305 BL33 key certificate identifier, used by BL2 to load the BL33 key
306 certificate.
307
308- **#define : NON\_TRUSTED\_FW\_CONTENT\_CERT\_ID**
309
310 BL33 content certificate identifier, used by BL2 to load the BL33 content
311 certificate.
312
313- **#define : FWU\_CERT\_ID**
314
315 Firmware Update (FWU) certificate identifier, used by NS\_BL1U to load the
316 FWU content certificate.
317
318- **#define : PLAT\_CRYPTOCELL\_BASE**
319
Dan Handley610e7e12018-03-01 18:44:00 +0000320 This defines the base address of Arm® TrustZone® CryptoCell and must be
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100321 defined if CryptoCell crypto driver is used for Trusted Board Boot. For
Dan Handley610e7e12018-03-01 18:44:00 +0000322 capable Arm platforms, this driver is used if ``ARM_CRYPTOCELL_INTEG`` is
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100323 set.
324
325If the AP Firmware Updater Configuration image, BL2U is used, the following
326must also be defined:
327
328- **#define : BL2U\_BASE**
329
330 Defines the base address in secure memory where BL1 copies the BL2U binary
331 image. Must be aligned on a page-size boundary.
332
333- **#define : BL2U\_LIMIT**
334
335 Defines the maximum address in secure memory that the BL2U image can occupy.
336
337- **#define : BL2U\_IMAGE\_ID**
338
339 BL2U image identifier, used by BL1 to fetch an image descriptor
340 corresponding to BL2U.
341
342If the SCP Firmware Update Configuration Image, SCP\_BL2U is used, the following
343must also be defined:
344
345- **#define : SCP\_BL2U\_IMAGE\_ID**
346
347 SCP\_BL2U image identifier, used by BL1 to fetch an image descriptor
348 corresponding to SCP\_BL2U.
Dan Handley610e7e12018-03-01 18:44:00 +0000349 NOTE: TF-A does not provide source code for this image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100350
351If the Non-Secure Firmware Updater ROM, NS\_BL1U is used, the following must
352also be defined:
353
354- **#define : NS\_BL1U\_BASE**
355
356 Defines the base address in non-secure ROM where NS\_BL1U executes.
357 Must be aligned on a page-size boundary.
Dan Handley610e7e12018-03-01 18:44:00 +0000358 NOTE: TF-A does not provide source code for this image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100359
360- **#define : NS\_BL1U\_IMAGE\_ID**
361
362 NS\_BL1U image identifier, used by BL1 to fetch an image descriptor
363 corresponding to NS\_BL1U.
364
365If the Non-Secure Firmware Updater, NS\_BL2U is used, the following must also
366be defined:
367
368- **#define : NS\_BL2U\_BASE**
369
370 Defines the base address in non-secure memory where NS\_BL2U executes.
371 Must be aligned on a page-size boundary.
Dan Handley610e7e12018-03-01 18:44:00 +0000372 NOTE: TF-A does not provide source code for this image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100373
374- **#define : NS\_BL2U\_IMAGE\_ID**
375
376 NS\_BL2U image identifier, used by BL1 to fetch an image descriptor
377 corresponding to NS\_BL2U.
378
379For the the Firmware update capability of TRUSTED BOARD BOOT, the following
380macros may also be defined:
381
382- **#define : PLAT\_FWU\_MAX\_SIMULTANEOUS\_IMAGES**
383
384 Total number of images that can be loaded simultaneously. If the platform
385 doesn't specify any value, it defaults to 10.
386
387If a SCP\_BL2 image is supported by the platform, the following constants must
388also be defined:
389
390- **#define : SCP\_BL2\_IMAGE\_ID**
391
392 SCP\_BL2 image identifier, used by BL2 to load SCP\_BL2 into secure memory
393 from platform storage before being transfered to the SCP.
394
395- **#define : SCP\_FW\_KEY\_CERT\_ID**
396
397 SCP\_BL2 key certificate identifier, used by BL2 to load the SCP\_BL2 key
398 certificate (mandatory when Trusted Board Boot is enabled).
399
400- **#define : SCP\_FW\_CONTENT\_CERT\_ID**
401
402 SCP\_BL2 content certificate identifier, used by BL2 to load the SCP\_BL2
403 content certificate (mandatory when Trusted Board Boot is enabled).
404
405If a BL32 image is supported by the platform, the following constants must
406also be defined:
407
408- **#define : BL32\_IMAGE\_ID**
409
410 BL32 image identifier, used by BL2 to load BL32.
411
412- **#define : TRUSTED\_OS\_FW\_KEY\_CERT\_ID**
413
414 BL32 key certificate identifier, used by BL2 to load the BL32 key
415 certificate (mandatory when Trusted Board Boot is enabled).
416
417- **#define : TRUSTED\_OS\_FW\_CONTENT\_CERT\_ID**
418
419 BL32 content certificate identifier, used by BL2 to load the BL32 content
420 certificate (mandatory when Trusted Board Boot is enabled).
421
422- **#define : BL32\_BASE**
423
424 Defines the base address in secure memory where BL2 loads the BL32 binary
425 image. Must be aligned on a page-size boundary.
426
427- **#define : BL32\_LIMIT**
428
429 Defines the maximum address that the BL32 image can occupy.
430
431If the Test Secure-EL1 Payload (TSP) instantiation of BL32 is supported by the
432platform, the following constants must also be defined:
433
434- **#define : TSP\_SEC\_MEM\_BASE**
435
436 Defines the base address of the secure memory used by the TSP image on the
437 platform. This must be at the same address or below ``BL32_BASE``.
438
439- **#define : TSP\_SEC\_MEM\_SIZE**
440
441 Defines the size of the secure memory used by the BL32 image on the
442 platform. ``TSP_SEC_MEM_BASE`` and ``TSP_SEC_MEM_SIZE`` must fully accomodate
443 the memory required by the BL32 image, defined by ``BL32_BASE`` and
444 ``BL32_LIMIT``.
445
446- **#define : TSP\_IRQ\_SEC\_PHY\_TIMER**
447
448 Defines the ID of the secure physical generic timer interrupt used by the
449 TSP's interrupt handling code.
450
451If the platform port uses the translation table library code, the following
452constants must also be defined:
453
454- **#define : PLAT\_XLAT\_TABLES\_DYNAMIC**
455
456 Optional flag that can be set per-image to enable the dynamic allocation of
457 regions even when the MMU is enabled. If not defined, only static
458 functionality will be available, if defined and set to 1 it will also
459 include the dynamic functionality.
460
461- **#define : MAX\_XLAT\_TABLES**
462
463 Defines the maximum number of translation tables that are allocated by the
464 translation table library code. To minimize the amount of runtime memory
465 used, choose the smallest value needed to map the required virtual addresses
466 for each BL stage. If ``PLAT_XLAT_TABLES_DYNAMIC`` flag is enabled for a BL
467 image, ``MAX_XLAT_TABLES`` must be defined to accommodate the dynamic regions
468 as well.
469
470- **#define : MAX\_MMAP\_REGIONS**
471
472 Defines the maximum number of regions that are allocated by the translation
473 table library code. A region consists of physical base address, virtual base
474 address, size and attributes (Device/Memory, RO/RW, Secure/Non-Secure), as
475 defined in the ``mmap_region_t`` structure. The platform defines the regions
476 that should be mapped. Then, the translation table library will create the
477 corresponding tables and descriptors at runtime. To minimize the amount of
478 runtime memory used, choose the smallest value needed to register the
479 required regions for each BL stage. If ``PLAT_XLAT_TABLES_DYNAMIC`` flag is
480 enabled for a BL image, ``MAX_MMAP_REGIONS`` must be defined to accommodate
481 the dynamic regions as well.
482
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100483- **#define : PLAT\_VIRT\_ADDR\_SPACE\_SIZE**
484
485 Defines the total size of the virtual address space in bytes. For example,
David Cunadoc1503122018-02-16 21:12:58 +0000486 for a 32 bit virtual address space, this value should be ``(1ULL << 32)``.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100487
488- **#define : PLAT\_PHY\_ADDR\_SPACE\_SIZE**
489
490 Defines the total size of the physical address space in bytes. For example,
David Cunadoc1503122018-02-16 21:12:58 +0000491 for a 32 bit physical address space, this value should be ``(1ULL << 32)``.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100492
493If the platform port uses the IO storage framework, the following constants
494must also be defined:
495
496- **#define : MAX\_IO\_DEVICES**
497
498 Defines the maximum number of registered IO devices. Attempting to register
499 more devices than this value using ``io_register_device()`` will fail with
500 -ENOMEM.
501
502- **#define : MAX\_IO\_HANDLES**
503
504 Defines the maximum number of open IO handles. Attempting to open more IO
505 entities than this value using ``io_open()`` will fail with -ENOMEM.
506
507- **#define : MAX\_IO\_BLOCK\_DEVICES**
508
509 Defines the maximum number of registered IO block devices. Attempting to
510 register more devices this value using ``io_dev_open()`` will fail
511 with -ENOMEM. MAX\_IO\_BLOCK\_DEVICES should be less than MAX\_IO\_DEVICES.
512 With this macro, multiple block devices could be supported at the same
513 time.
514
515If the platform needs to allocate data within the per-cpu data framework in
516BL31, it should define the following macro. Currently this is only required if
517the platform decides not to use the coherent memory section by undefining the
518``USE_COHERENT_MEM`` build flag. In this case, the framework allocates the
519required memory within the the per-cpu data to minimize wastage.
520
521- **#define : PLAT\_PCPU\_DATA\_SIZE**
522
523 Defines the memory (in bytes) to be reserved within the per-cpu data
524 structure for use by the platform layer.
525
526The following constants are optional. They should be defined when the platform
Dan Handley610e7e12018-03-01 18:44:00 +0000527memory layout implies some image overlaying like in Arm standard platforms.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100528
529- **#define : BL31\_PROGBITS\_LIMIT**
530
531 Defines the maximum address in secure RAM that the BL31's progbits sections
532 can occupy.
533
534- **#define : TSP\_PROGBITS\_LIMIT**
535
536 Defines the maximum address that the TSP's progbits sections can occupy.
537
538If the platform port uses the PL061 GPIO driver, the following constant may
539optionally be defined:
540
541- **PLAT\_PL061\_MAX\_GPIOS**
542 Maximum number of GPIOs required by the platform. This allows control how
543 much memory is allocated for PL061 GPIO controllers. The default value is
544
545 #. $(eval $(call add\_define,PLAT\_PL061\_MAX\_GPIOS))
546
547If the platform port uses the partition driver, the following constant may
548optionally be defined:
549
550- **PLAT\_PARTITION\_MAX\_ENTRIES**
551 Maximum number of partition entries required by the platform. This allows
552 control how much memory is allocated for partition entries. The default
553 value is 128.
554 `For example, define the build flag in platform.mk`_:
555 PLAT\_PARTITION\_MAX\_ENTRIES := 12
556 $(eval $(call add\_define,PLAT\_PARTITION\_MAX\_ENTRIES))
557
558The following constant is optional. It should be defined to override the default
559behaviour of the ``assert()`` function (for example, to save memory).
560
561- **PLAT\_LOG\_LEVEL\_ASSERT**
562 If ``PLAT_LOG_LEVEL_ASSERT`` is higher or equal than ``LOG_LEVEL_VERBOSE``,
563 ``assert()`` prints the name of the file, the line number and the asserted
564 expression. Else if it is higher than ``LOG_LEVEL_INFO``, it prints the file
565 name and the line number. Else if it is lower than ``LOG_LEVEL_INFO``, it
566 doesn't print anything to the console. If ``PLAT_LOG_LEVEL_ASSERT`` isn't
567 defined, it defaults to ``LOG_LEVEL``.
568
Dimitris Papastamos60346db2017-12-13 10:54:37 +0000569If the platform port uses the Activity Monitor Unit, the following constants
570may be defined:
571
572- **PLAT\_AMU\_GROUP1\_COUNTERS\_MASK**
573 This mask reflects the set of group counters that should be enabled. The
574 maximum number of group 1 counters supported by AMUv1 is 16 so the mask
575 can be at most 0xffff. If the platform does not define this mask, no group 1
576 counters are enabled. If the platform defines this mask, the following
577 constant needs to also be defined.
578
579- **PLAT\_AMU\_GROUP1\_NR\_COUNTERS**
580 This value is used to allocate an array to save and restore the counters
581 specified by ``PLAT_AMU_GROUP1_COUNTERS_MASK`` on CPU suspend.
582 This value should be equal to the highest bit position set in the
583 mask, plus 1. The maximum number of group 1 counters in AMUv1 is 16.
584
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100585File : plat\_macros.S [mandatory]
586~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
587
588Each platform must ensure a file of this name is in the system include path with
Dan Handley610e7e12018-03-01 18:44:00 +0000589the following macro defined. In the Arm development platforms, this file is
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100590found in ``plat/arm/board/<plat_name>/include/plat_macros.S``.
591
592- **Macro : plat\_crash\_print\_regs**
593
594 This macro allows the crash reporting routine to print relevant platform
595 registers in case of an unhandled exception in BL31. This aids in debugging
596 and this macro can be defined to be empty in case register reporting is not
597 desired.
598
599 For instance, GIC or interconnect registers may be helpful for
600 troubleshooting.
601
602Handling Reset
603--------------
604
605BL1 by default implements the reset vector where execution starts from a cold
606or warm boot. BL31 can be optionally set as a reset vector using the
607``RESET_TO_BL31`` make variable.
608
609For each CPU, the reset vector code is responsible for the following tasks:
610
611#. Distinguishing between a cold boot and a warm boot.
612
613#. In the case of a cold boot and the CPU being a secondary CPU, ensuring that
614 the CPU is placed in a platform-specific state until the primary CPU
615 performs the necessary steps to remove it from this state.
616
617#. In the case of a warm boot, ensuring that the CPU jumps to a platform-
618 specific address in the BL31 image in the same processor mode as it was
619 when released from reset.
620
621The following functions need to be implemented by the platform port to enable
622reset vector code to perform the above tasks.
623
624Function : plat\_get\_my\_entrypoint() [mandatory when PROGRAMMABLE\_RESET\_ADDRESS == 0]
625~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
626
627::
628
629 Argument : void
630 Return : uintptr_t
631
632This function is called with the MMU and caches disabled
633(``SCTLR_EL3.M`` = 0 and ``SCTLR_EL3.C`` = 0). The function is responsible for
634distinguishing between a warm and cold reset for the current CPU using
635platform-specific means. If it's a warm reset, then it returns the warm
636reset entrypoint point provided to ``plat_setup_psci_ops()`` during
637BL31 initialization. If it's a cold reset then this function must return zero.
638
639This function does not follow the Procedure Call Standard used by the
Dan Handley610e7e12018-03-01 18:44:00 +0000640Application Binary Interface for the Arm 64-bit architecture. The caller should
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100641not assume that callee saved registers are preserved across a call to this
642function.
643
644This function fulfills requirement 1 and 3 listed above.
645
646Note that for platforms that support programming the reset address, it is
647expected that a CPU will start executing code directly at the right address,
648both on a cold and warm reset. In this case, there is no need to identify the
649type of reset nor to query the warm reset entrypoint. Therefore, implementing
650this function is not required on such platforms.
651
652Function : plat\_secondary\_cold\_boot\_setup() [mandatory when COLD\_BOOT\_SINGLE\_CPU == 0]
653~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
654
655::
656
657 Argument : void
658
659This function is called with the MMU and data caches disabled. It is responsible
660for placing the executing secondary CPU in a platform-specific state until the
661primary CPU performs the necessary actions to bring it out of that state and
662allow entry into the OS. This function must not return.
663
Dan Handley610e7e12018-03-01 18:44:00 +0000664In the Arm FVP port, when using the normal boot flow, each secondary CPU powers
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100665itself off. The primary CPU is responsible for powering up the secondary CPUs
666when normal world software requires them. When booting an EL3 payload instead,
667they stay powered on and are put in a holding pen until their mailbox gets
668populated.
669
670This function fulfills requirement 2 above.
671
672Note that for platforms that can't release secondary CPUs out of reset, only the
673primary CPU will execute the cold boot code. Therefore, implementing this
674function is not required on such platforms.
675
676Function : plat\_is\_my\_cpu\_primary() [mandatory when COLD\_BOOT\_SINGLE\_CPU == 0]
677~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
678
679::
680
681 Argument : void
682 Return : unsigned int
683
684This function identifies whether the current CPU is the primary CPU or a
685secondary CPU. A return value of zero indicates that the CPU is not the
686primary CPU, while a non-zero return value indicates that the CPU is the
687primary CPU.
688
689Note that for platforms that can't release secondary CPUs out of reset, only the
690primary CPU will execute the cold boot code. Therefore, there is no need to
691distinguish between primary and secondary CPUs and implementing this function is
692not required.
693
694Function : platform\_mem\_init() [mandatory]
695~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
696
697::
698
699 Argument : void
700 Return : void
701
702This function is called before any access to data is made by the firmware, in
703order to carry out any essential memory initialization.
704
705Function: plat\_get\_rotpk\_info()
706~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
707
708::
709
710 Argument : void *, void **, unsigned int *, unsigned int *
711 Return : int
712
713This function is mandatory when Trusted Board Boot is enabled. It returns a
714pointer to the ROTPK stored in the platform (or a hash of it) and its length.
715The ROTPK must be encoded in DER format according to the following ASN.1
716structure:
717
718::
719
720 AlgorithmIdentifier ::= SEQUENCE {
721 algorithm OBJECT IDENTIFIER,
722 parameters ANY DEFINED BY algorithm OPTIONAL
723 }
724
725 SubjectPublicKeyInfo ::= SEQUENCE {
726 algorithm AlgorithmIdentifier,
727 subjectPublicKey BIT STRING
728 }
729
730In case the function returns a hash of the key:
731
732::
733
734 DigestInfo ::= SEQUENCE {
735 digestAlgorithm AlgorithmIdentifier,
736 digest OCTET STRING
737 }
738
739The function returns 0 on success. Any other value is treated as error by the
740Trusted Board Boot. The function also reports extra information related
741to the ROTPK in the flags parameter:
742
743::
744
745 ROTPK_IS_HASH : Indicates that the ROTPK returned by the platform is a
746 hash.
747 ROTPK_NOT_DEPLOYED : This allows the platform to skip certificate ROTPK
748 verification while the platform ROTPK is not deployed.
749 When this flag is set, the function does not need to
750 return a platform ROTPK, and the authentication
751 framework uses the ROTPK in the certificate without
752 verifying it against the platform value. This flag
753 must not be used in a deployed production environment.
754
755Function: plat\_get\_nv\_ctr()
756~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
757
758::
759
760 Argument : void *, unsigned int *
761 Return : int
762
763This function is mandatory when Trusted Board Boot is enabled. It returns the
764non-volatile counter value stored in the platform in the second argument. The
765cookie in the first argument may be used to select the counter in case the
766platform provides more than one (for example, on platforms that use the default
767TBBR CoT, the cookie will correspond to the OID values defined in
768TRUSTED\_FW\_NVCOUNTER\_OID or NON\_TRUSTED\_FW\_NVCOUNTER\_OID).
769
770The function returns 0 on success. Any other value means the counter value could
771not be retrieved from the platform.
772
773Function: plat\_set\_nv\_ctr()
774~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
775
776::
777
778 Argument : void *, unsigned int
779 Return : int
780
781This function is mandatory when Trusted Board Boot is enabled. It sets a new
782counter value in the platform. The cookie in the first argument may be used to
783select the counter (as explained in plat\_get\_nv\_ctr()). The second argument is
784the updated counter value to be written to the NV counter.
785
786The function returns 0 on success. Any other value means the counter value could
787not be updated.
788
789Function: plat\_set\_nv\_ctr2()
790~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
791
792::
793
794 Argument : void *, const auth_img_desc_t *, unsigned int
795 Return : int
796
797This function is optional when Trusted Board Boot is enabled. If this
798interface is defined, then ``plat_set_nv_ctr()`` need not be defined. The
799first argument passed is a cookie and is typically used to
800differentiate between a Non Trusted NV Counter and a Trusted NV
801Counter. The second argument is a pointer to an authentication image
802descriptor and may be used to decide if the counter is allowed to be
803updated or not. The third argument is the updated counter value to
804be written to the NV counter.
805
806The function returns 0 on success. Any other value means the counter value
807either could not be updated or the authentication image descriptor indicates
808that it is not allowed to be updated.
809
810Common mandatory function modifications
811---------------------------------------
812
813The following functions are mandatory functions which need to be implemented
814by the platform port.
815
816Function : plat\_my\_core\_pos()
817~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
818
819::
820
821 Argument : void
822 Return : unsigned int
823
824This funtion returns the index of the calling CPU which is used as a
825CPU-specific linear index into blocks of memory (for example while allocating
826per-CPU stacks). This function will be invoked very early in the
827initialization sequence which mandates that this function should be
828implemented in assembly and should not rely on the avalability of a C
829runtime environment. This function can clobber x0 - x8 and must preserve
830x9 - x29.
831
832This function plays a crucial role in the power domain topology framework in
833PSCI and details of this can be found in `Power Domain Topology Design`_.
834
835Function : plat\_core\_pos\_by\_mpidr()
836~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
837
838::
839
840 Argument : u_register_t
841 Return : int
842
843This function validates the ``MPIDR`` of a CPU and converts it to an index,
844which can be used as a CPU-specific linear index into blocks of memory. In
845case the ``MPIDR`` is invalid, this function returns -1. This function will only
846be invoked by BL31 after the power domain topology is initialized and can
Dan Handley610e7e12018-03-01 18:44:00 +0000847utilize the C runtime environment. For further details about how TF-A
848represents the power domain topology and how this relates to the linear CPU
849index, please refer `Power Domain Topology Design`_.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100850
851Common optional modifications
852-----------------------------
853
854The following are helper functions implemented by the firmware that perform
855common platform-specific tasks. A platform may choose to override these
856definitions.
857
858Function : plat\_set\_my\_stack()
859~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
860
861::
862
863 Argument : void
864 Return : void
865
866This function sets the current stack pointer to the normal memory stack that
867has been allocated for the current CPU. For BL images that only require a
868stack for the primary CPU, the UP version of the function is used. The size
869of the stack allocated to each CPU is specified by the platform defined
870constant ``PLATFORM_STACK_SIZE``.
871
872Common implementations of this function for the UP and MP BL images are
873provided in `plat/common/aarch64/platform\_up\_stack.S`_ and
874`plat/common/aarch64/platform\_mp\_stack.S`_
875
876Function : plat\_get\_my\_stack()
877~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
878
879::
880
881 Argument : void
882 Return : uintptr_t
883
884This function returns the base address of the normal memory stack that
885has been allocated for the current CPU. For BL images that only require a
886stack for the primary CPU, the UP version of the function is used. The size
887of the stack allocated to each CPU is specified by the platform defined
888constant ``PLATFORM_STACK_SIZE``.
889
890Common implementations of this function for the UP and MP BL images are
891provided in `plat/common/aarch64/platform\_up\_stack.S`_ and
892`plat/common/aarch64/platform\_mp\_stack.S`_
893
894Function : plat\_report\_exception()
895~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
896
897::
898
899 Argument : unsigned int
900 Return : void
901
902A platform may need to report various information about its status when an
903exception is taken, for example the current exception level, the CPU security
904state (secure/non-secure), the exception type, and so on. This function is
905called in the following circumstances:
906
907- In BL1, whenever an exception is taken.
908- In BL2, whenever an exception is taken.
909
910The default implementation doesn't do anything, to avoid making assumptions
911about the way the platform displays its status information.
912
913For AArch64, this function receives the exception type as its argument.
914Possible values for exceptions types are listed in the
915`include/common/bl\_common.h`_ header file. Note that these constants are not
Dan Handley610e7e12018-03-01 18:44:00 +0000916related to any architectural exception code; they are just a TF-A convention.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100917
918For AArch32, this function receives the exception mode as its argument.
919Possible values for exception modes are listed in the
920`include/lib/aarch32/arch.h`_ header file.
921
922Function : plat\_reset\_handler()
923~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
924
925::
926
927 Argument : void
928 Return : void
929
930A platform may need to do additional initialization after reset. This function
931allows the platform to do the platform specific intializations. Platform
932specific errata workarounds could also be implemented here. The api should
933preserve the values of callee saved registers x19 to x29.
934
935The default implementation doesn't do anything. If a platform needs to override
936the default implementation, refer to the `Firmware Design`_ for general
937guidelines.
938
939Function : plat\_disable\_acp()
940~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
941
942::
943
944 Argument : void
945 Return : void
946
John Tsichritzis6dda9762018-07-23 09:18:04 +0100947This API allows a platform to disable the Accelerator Coherency Port (if
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100948present) during a cluster power down sequence. The default weak implementation
John Tsichritzis6dda9762018-07-23 09:18:04 +0100949doesn't do anything. Since this API is called during the power down sequence,
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100950it has restrictions for stack usage and it can use the registers x0 - x17 as
951scratch registers. It should preserve the value in x18 register as it is used
952by the caller to store the return address.
953
954Function : plat\_error\_handler()
955~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
956
957::
958
959 Argument : int
960 Return : void
961
962This API is called when the generic code encounters an error situation from
963which it cannot continue. It allows the platform to perform error reporting or
964recovery actions (for example, reset the system). This function must not return.
965
966The parameter indicates the type of error using standard codes from ``errno.h``.
967Possible errors reported by the generic code are:
968
969- ``-EAUTH``: a certificate or image could not be authenticated (when Trusted
970 Board Boot is enabled)
971- ``-ENOENT``: the requested image or certificate could not be found or an IO
972 error was detected
Dan Handley610e7e12018-03-01 18:44:00 +0000973- ``-ENOMEM``: resources exhausted. TF-A does not use dynamic memory, so this
974 error is usually an indication of an incorrect array size
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100975
976The default implementation simply spins.
977
978Function : plat\_panic\_handler()
979~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
980
981::
982
983 Argument : void
984 Return : void
985
986This API is called when the generic code encounters an unexpected error
987situation from which it cannot recover. This function must not return,
988and must be implemented in assembly because it may be called before the C
989environment is initialized.
990
991Note: The address from where it was called is stored in x30 (Link Register).
992The default implementation simply spins.
993
994Function : plat\_get\_bl\_image\_load\_info()
995~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
996
997::
998
999 Argument : void
1000 Return : bl_load_info_t *
1001
1002This function returns pointer to the list of images that the platform has
Soby Mathew97b1bff2018-09-27 16:46:41 +01001003populated to load. This function is invoked in BL2 to load the
1004BL3xx images.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001005
1006Function : plat\_get\_next\_bl\_params()
1007~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1008
1009::
1010
1011 Argument : void
1012 Return : bl_params_t *
1013
1014This function returns a pointer to the shared memory that the platform has
Dan Handley610e7e12018-03-01 18:44:00 +00001015kept aside to pass TF-A related information that next BL image needs. This
Soby Mathew97b1bff2018-09-27 16:46:41 +01001016function is invoked in BL2 to pass this information to the next BL
1017image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001018
1019Function : plat\_get\_stack\_protector\_canary()
1020~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1021
1022::
1023
1024 Argument : void
1025 Return : u_register_t
1026
1027This function returns a random value that is used to initialize the canary used
1028when the stack protector is enabled with ENABLE\_STACK\_PROTECTOR. A predictable
1029value will weaken the protection as the attacker could easily write the right
1030value as part of the attack most of the time. Therefore, it should return a
1031true random number.
1032
1033Note: For the protection to be effective, the global data need to be placed at
1034a lower address than the stack bases. Failure to do so would allow an attacker
1035to overwrite the canary as part of the stack buffer overflow attack.
1036
1037Function : plat\_flush\_next\_bl\_params()
1038~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1039
1040::
1041
1042 Argument : void
1043 Return : void
1044
1045This function flushes to main memory all the image params that are passed to
Soby Mathew97b1bff2018-09-27 16:46:41 +01001046next image. This function is invoked in BL2 to flush this information
1047to the next BL image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001048
Soby Mathewaaf15f52017-09-04 11:49:29 +01001049Function : plat\_log\_get\_prefix()
John Tsichritzis30f89642018-06-07 16:31:34 +01001050~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Soby Mathewaaf15f52017-09-04 11:49:29 +01001051
1052::
1053
1054 Argument : unsigned int
1055 Return : const char *
1056
1057This function defines the prefix string corresponding to the `log_level` to be
Dan Handley610e7e12018-03-01 18:44:00 +00001058prepended to all the log output from TF-A. The `log_level` (argument) will
1059correspond to one of the standard log levels defined in debug.h. The platform
1060can override the common implementation to define a different prefix string for
John Tsichritzis30f89642018-06-07 16:31:34 +01001061the log output. The implementation should be robust to future changes that
Dan Handley610e7e12018-03-01 18:44:00 +00001062increase the number of log levels.
Soby Mathewaaf15f52017-09-04 11:49:29 +01001063
John Tsichritzis30f89642018-06-07 16:31:34 +01001064Function : plat\_get\_mbedtls\_heap()
1065~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1066
1067::
1068
1069 Arguments : void **heap_addr, size_t *heap_size
John Tsichritzisc34341a2018-07-30 13:41:52 +01001070 Return : int
John Tsichritzis30f89642018-06-07 16:31:34 +01001071
1072This function is invoked during Mbed TLS library initialisation to get
1073a heap, by means of a starting address and a size. This heap will then be used
John Tsichritzisc34341a2018-07-30 13:41:52 +01001074internally by the Mbed TLS library. The heap is requested from the current BL
1075stage, i.e. the current BL image inside which Mbed TLS is used.
John Tsichritzis30f89642018-06-07 16:31:34 +01001076
John Tsichritzisc34341a2018-07-30 13:41:52 +01001077In the default implementation a heap is statically allocated inside every image
1078(i.e. every BL stage) that utilises Mbed TLS. So, in this case, the function
1079simply returns the address and size of this "pre-allocated" heap. However, by
1080overriding the default implementation, platforms have the potential to optimise
1081memory usage. For example, on some Arm platforms, the Mbed TLS heap is shared
1082between BL1 and BL2 stages and, thus, the necessary space is not reserved
1083twice.
John Tsichritzis30f89642018-06-07 16:31:34 +01001084
John Tsichritzisc34341a2018-07-30 13:41:52 +01001085On success the function should return 0 and a negative error code otherwise.
John Tsichritzis30f89642018-06-07 16:31:34 +01001086
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001087Modifications specific to a Boot Loader stage
1088---------------------------------------------
1089
1090Boot Loader Stage 1 (BL1)
1091-------------------------
1092
1093BL1 implements the reset vector where execution starts from after a cold or
1094warm boot. For each CPU, BL1 is responsible for the following tasks:
1095
1096#. Handling the reset as described in section 2.2
1097
1098#. In the case of a cold boot and the CPU being the primary CPU, ensuring that
1099 only this CPU executes the remaining BL1 code, including loading and passing
1100 control to the BL2 stage.
1101
1102#. Identifying and starting the Firmware Update process (if required).
1103
1104#. Loading the BL2 image from non-volatile storage into secure memory at the
1105 address specified by the platform defined constant ``BL2_BASE``.
1106
1107#. Populating a ``meminfo`` structure with the following information in memory,
1108 accessible by BL2 immediately upon entry.
1109
1110 ::
1111
1112 meminfo.total_base = Base address of secure RAM visible to BL2
1113 meminfo.total_size = Size of secure RAM visible to BL2
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001114
Soby Mathew97b1bff2018-09-27 16:46:41 +01001115 By default, BL1 places this ``meminfo`` structure at the end of secure
1116 memory visible to BL2.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001117
Soby Mathewb1bf0442018-02-16 14:52:52 +00001118 It is possible for the platform to decide where it wants to place the
1119 ``meminfo`` structure for BL2 or restrict the amount of memory visible to
1120 BL2 by overriding the weak default implementation of
1121 ``bl1_plat_handle_post_image_load`` API.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001122
1123The following functions need to be implemented by the platform port to enable
1124BL1 to perform the above tasks.
1125
1126Function : bl1\_early\_platform\_setup() [mandatory]
1127~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1128
1129::
1130
1131 Argument : void
1132 Return : void
1133
1134This function executes with the MMU and data caches disabled. It is only called
1135by the primary CPU.
1136
Dan Handley610e7e12018-03-01 18:44:00 +00001137On Arm standard platforms, this function:
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001138
1139- Enables a secure instance of SP805 to act as the Trusted Watchdog.
1140
1141- Initializes a UART (PL011 console), which enables access to the ``printf``
1142 family of functions in BL1.
1143
1144- Enables issuing of snoop and DVM (Distributed Virtual Memory) requests to
1145 the CCI slave interface corresponding to the cluster that includes the
1146 primary CPU.
1147
1148Function : bl1\_plat\_arch\_setup() [mandatory]
1149~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1150
1151::
1152
1153 Argument : void
1154 Return : void
1155
1156This function performs any platform-specific and architectural setup that the
1157platform requires. Platform-specific setup might include configuration of
1158memory controllers and the interconnect.
1159
Dan Handley610e7e12018-03-01 18:44:00 +00001160In Arm standard platforms, this function enables the MMU.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001161
1162This function helps fulfill requirement 2 above.
1163
1164Function : bl1\_platform\_setup() [mandatory]
1165~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1166
1167::
1168
1169 Argument : void
1170 Return : void
1171
1172This function executes with the MMU and data caches enabled. It is responsible
1173for performing any remaining platform-specific setup that can occur after the
1174MMU and data cache have been enabled.
1175
Roberto Vargas0cd866c2017-12-12 10:39:44 +00001176if support for multiple boot sources is required, it initializes the boot
1177sequence used by plat\_try\_next\_boot\_source().
1178
Dan Handley610e7e12018-03-01 18:44:00 +00001179In Arm standard platforms, this function initializes the storage abstraction
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001180layer used to load the next bootloader image.
1181
1182This function helps fulfill requirement 4 above.
1183
1184Function : bl1\_plat\_sec\_mem\_layout() [mandatory]
1185~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1186
1187::
1188
1189 Argument : void
1190 Return : meminfo *
1191
1192This function should only be called on the cold boot path. It executes with the
1193MMU and data caches enabled. The pointer returned by this function must point to
1194a ``meminfo`` structure containing the extents and availability of secure RAM for
1195the BL1 stage.
1196
1197::
1198
1199 meminfo.total_base = Base address of secure RAM visible to BL1
1200 meminfo.total_size = Size of secure RAM visible to BL1
1201 meminfo.free_base = Base address of secure RAM available for allocation
1202 to BL1
1203 meminfo.free_size = Size of secure RAM available for allocation to BL1
1204
1205This information is used by BL1 to load the BL2 image in secure RAM. BL1 also
1206populates a similar structure to tell BL2 the extents of memory available for
1207its own use.
1208
1209This function helps fulfill requirements 4 and 5 above.
1210
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001211Function : bl1\_plat\_prepare\_exit() [optional]
1212~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1213
1214::
1215
1216 Argument : entry_point_info_t *
1217 Return : void
1218
1219This function is called prior to exiting BL1 in response to the
1220``BL1_SMC_RUN_IMAGE`` SMC request raised by BL2. It should be used to perform
1221platform specific clean up or bookkeeping operations before transferring
1222control to the next image. It receives the address of the ``entry_point_info_t``
1223structure passed from BL2. This function runs with MMU disabled.
1224
1225Function : bl1\_plat\_set\_ep\_info() [optional]
1226~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1227
1228::
1229
1230 Argument : unsigned int image_id, entry_point_info_t *ep_info
1231 Return : void
1232
1233This function allows platforms to override ``ep_info`` for the given ``image_id``.
1234
1235The default implementation just returns.
1236
1237Function : bl1\_plat\_get\_next\_image\_id() [optional]
1238~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1239
1240::
1241
1242 Argument : void
1243 Return : unsigned int
1244
1245This and the following function must be overridden to enable the FWU feature.
1246
1247BL1 calls this function after platform setup to identify the next image to be
1248loaded and executed. If the platform returns ``BL2_IMAGE_ID`` then BL1 proceeds
1249with the normal boot sequence, which loads and executes BL2. If the platform
1250returns a different image id, BL1 assumes that Firmware Update is required.
1251
Dan Handley610e7e12018-03-01 18:44:00 +00001252The default implementation always returns ``BL2_IMAGE_ID``. The Arm development
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001253platforms override this function to detect if firmware update is required, and
1254if so, return the first image in the firmware update process.
1255
1256Function : bl1\_plat\_get\_image\_desc() [optional]
1257~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1258
1259::
1260
1261 Argument : unsigned int image_id
1262 Return : image_desc_t *
1263
1264BL1 calls this function to get the image descriptor information ``image_desc_t``
1265for the provided ``image_id`` from the platform.
1266
Dan Handley610e7e12018-03-01 18:44:00 +00001267The default implementation always returns a common BL2 image descriptor. Arm
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001268standard platforms return an image descriptor corresponding to BL2 or one of
1269the firmware update images defined in the Trusted Board Boot Requirements
1270specification.
1271
Masahiro Yamada43d20b32018-02-01 16:46:18 +09001272Function : bl1\_plat\_handle\_pre\_image\_load() [optional]
1273~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1274
1275::
1276
Soby Mathew2f38ce32018-02-08 17:45:12 +00001277 Argument : unsigned int image_id
Masahiro Yamada43d20b32018-02-01 16:46:18 +09001278 Return : int
1279
1280This function can be used by the platforms to update/use image information
Soby Mathew2f38ce32018-02-08 17:45:12 +00001281corresponding to ``image_id``. This function is invoked in BL1, both in cold
1282boot and FWU code path, before loading the image.
Masahiro Yamada43d20b32018-02-01 16:46:18 +09001283
1284Function : bl1\_plat\_handle\_post\_image\_load() [optional]
1285~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1286
1287::
1288
Soby Mathew2f38ce32018-02-08 17:45:12 +00001289 Argument : unsigned int image_id
Masahiro Yamada43d20b32018-02-01 16:46:18 +09001290 Return : int
1291
1292This function can be used by the platforms to update/use image information
Soby Mathew2f38ce32018-02-08 17:45:12 +00001293corresponding to ``image_id``. This function is invoked in BL1, both in cold
1294boot and FWU code path, after loading and authenticating the image.
Masahiro Yamada43d20b32018-02-01 16:46:18 +09001295
Soby Mathewb1bf0442018-02-16 14:52:52 +00001296The default weak implementation of this function calculates the amount of
1297Trusted SRAM that can be used by BL2 and allocates a ``meminfo_t``
1298structure at the beginning of this free memory and populates it. The address
1299of ``meminfo_t`` structure is updated in ``arg1`` of the entrypoint
1300information to BL2.
1301
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001302Function : bl1\_plat\_fwu\_done() [optional]
1303~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1304
1305::
1306
1307 Argument : unsigned int image_id, uintptr_t image_src,
1308 unsigned int image_size
1309 Return : void
1310
1311BL1 calls this function when the FWU process is complete. It must not return.
1312The platform may override this function to take platform specific action, for
1313example to initiate the normal boot flow.
1314
1315The default implementation spins forever.
1316
1317Function : bl1\_plat\_mem\_check() [mandatory]
1318~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1319
1320::
1321
1322 Argument : uintptr_t mem_base, unsigned int mem_size,
1323 unsigned int flags
1324 Return : int
1325
1326BL1 calls this function while handling FWU related SMCs, more specifically when
1327copying or authenticating an image. Its responsibility is to ensure that the
1328region of memory identified by ``mem_base`` and ``mem_size`` is mapped in BL1, and
1329that this memory corresponds to either a secure or non-secure memory region as
1330indicated by the security state of the ``flags`` argument.
1331
1332This function can safely assume that the value resulting from the addition of
1333``mem_base`` and ``mem_size`` fits into a ``uintptr_t`` type variable and does not
1334overflow.
1335
1336This function must return 0 on success, a non-null error code otherwise.
1337
1338The default implementation of this function asserts therefore platforms must
1339override it when using the FWU feature.
1340
1341Boot Loader Stage 2 (BL2)
1342-------------------------
1343
1344The BL2 stage is executed only by the primary CPU, which is determined in BL1
1345using the ``platform_is_primary_cpu()`` function. BL1 passed control to BL2 at
Soby Mathew97b1bff2018-09-27 16:46:41 +01001346``BL2_BASE``. BL2 executes in Secure EL1 and and invokes
1347``plat_get_bl_image_load_info()`` to retrieve the list of images to load from
1348non-volatile storage to secure/non-secure RAM. After all the images are loaded
1349then BL2 invokes ``plat_get_next_bl_params()`` to get the list of executable
1350images to be passed to the next BL image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001351
1352The following functions must be implemented by the platform port to enable BL2
1353to perform the above tasks.
1354
Soby Mathew97b1bff2018-09-27 16:46:41 +01001355Function : bl2\_early\_platform\_setup2() [mandatory]
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001356~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1357
1358::
1359
Soby Mathew97b1bff2018-09-27 16:46:41 +01001360 Argument : u_register_t, u_register_t, u_register_t, u_register_t
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001361 Return : void
1362
1363This function executes with the MMU and data caches disabled. It is only called
Soby Mathew97b1bff2018-09-27 16:46:41 +01001364by the primary CPU. The 4 arguments are passed by BL1 to BL2 and these arguments
1365are platform specific.
1366
1367On Arm standard platforms, the arguments received are :
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001368
Soby Mathew97b1bff2018-09-27 16:46:41 +01001369 arg0 - Points to load address of HW_CONFIG if present
1370
1371 arg1 - ``meminfo`` structure populated by BL1. The platform copies
1372 the contents of ``meminfo`` as it may be subsequently overwritten by BL2.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001373
Dan Handley610e7e12018-03-01 18:44:00 +00001374On Arm standard platforms, this function also:
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001375
1376- Initializes a UART (PL011 console), which enables access to the ``printf``
1377 family of functions in BL2.
1378
1379- Initializes the storage abstraction layer used to load further bootloader
1380 images. It is necessary to do this early on platforms with a SCP\_BL2 image,
1381 since the later ``bl2_platform_setup`` must be done after SCP\_BL2 is loaded.
1382
1383Function : bl2\_plat\_arch\_setup() [mandatory]
1384~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1385
1386::
1387
1388 Argument : void
1389 Return : void
1390
1391This function executes with the MMU and data caches disabled. It is only called
1392by the primary CPU.
1393
1394The purpose of this function is to perform any architectural initialization
1395that varies across platforms.
1396
Dan Handley610e7e12018-03-01 18:44:00 +00001397On Arm standard platforms, this function enables the MMU.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001398
1399Function : bl2\_platform\_setup() [mandatory]
1400~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1401
1402::
1403
1404 Argument : void
1405 Return : void
1406
1407This function may execute with the MMU and data caches enabled if the platform
1408port does the necessary initialization in ``bl2_plat_arch_setup()``. It is only
1409called by the primary CPU.
1410
1411The purpose of this function is to perform any platform initialization
1412specific to BL2.
1413
Dan Handley610e7e12018-03-01 18:44:00 +00001414In Arm standard platforms, this function performs security setup, including
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001415configuration of the TrustZone controller to allow non-secure masters access
1416to most of DRAM. Part of DRAM is reserved for secure world use.
1417
Masahiro Yamada02a0d3d2018-02-01 16:45:51 +09001418Function : bl2\_plat\_handle\_pre\_image\_load() [optional]
1419~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001420
1421::
1422
1423 Argument : unsigned int
1424 Return : int
1425
1426This function can be used by the platforms to update/use image information
Masahiro Yamada02a0d3d2018-02-01 16:45:51 +09001427for given ``image_id``. This function is currently invoked in BL2 before
Soby Mathew97b1bff2018-09-27 16:46:41 +01001428loading each image.
Masahiro Yamada02a0d3d2018-02-01 16:45:51 +09001429
1430Function : bl2\_plat\_handle\_post\_image\_load() [optional]
1431~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1432
1433::
1434
1435 Argument : unsigned int
1436 Return : int
1437
1438This function can be used by the platforms to update/use image information
1439for given ``image_id``. This function is currently invoked in BL2 after
Soby Mathew97b1bff2018-09-27 16:46:41 +01001440loading each image.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001441
Roberto Vargasbc1ae1f2017-09-26 12:53:01 +01001442Function : bl2\_plat\_preload\_setup [optional]
1443~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1444
1445::
John Tsichritzisee10e792018-06-06 09:38:10 +01001446
Roberto Vargasbc1ae1f2017-09-26 12:53:01 +01001447 Argument : void
1448 Return : void
1449
1450This optional function performs any BL2 platform initialization
1451required before image loading, that is not done later in
1452bl2\_platform\_setup(). Specifically, if support for multiple
1453boot sources is required, it initializes the boot sequence used by
1454plat\_try\_next\_boot\_source().
1455
1456Function : plat\_try\_next\_boot\_source() [optional]
1457~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1458
1459::
John Tsichritzisee10e792018-06-06 09:38:10 +01001460
Roberto Vargasbc1ae1f2017-09-26 12:53:01 +01001461 Argument : void
1462 Return : int
1463
1464This optional function passes to the next boot source in the redundancy
1465sequence.
1466
1467This function moves the current boot redundancy source to the next
1468element in the boot sequence. If there are no more boot sources then it
1469must return 0, otherwise it must return 1. The default implementation
1470of this always returns 0.
1471
Roberto Vargasb1584272017-11-20 13:36:10 +00001472Boot Loader Stage 2 (BL2) at EL3
1473--------------------------------
1474
Dan Handley610e7e12018-03-01 18:44:00 +00001475When the platform has a non-TF-A Boot ROM it is desirable to jump
1476directly to BL2 instead of TF-A BL1. In this case BL2 is expected to
Roberto Vargasb1584272017-11-20 13:36:10 +00001477execute at EL3 instead of executing at EL1. Refer to the `Firmware
1478Design`_ for more information.
1479
1480All mandatory functions of BL2 must be implemented, except the functions
1481bl2\_early\_platform\_setup and bl2\_el3\_plat\_arch\_setup, because
1482their work is done now by bl2\_el3\_early\_platform\_setup and
1483bl2\_el3\_plat\_arch\_setup. These functions should generally implement
1484the bl1\_plat\_xxx() and bl2\_plat\_xxx() functionality combined.
1485
1486
1487Function : bl2\_el3\_early\_platform\_setup() [mandatory]
1488~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1489
1490::
John Tsichritzisee10e792018-06-06 09:38:10 +01001491
Roberto Vargasb1584272017-11-20 13:36:10 +00001492 Argument : u_register_t, u_register_t, u_register_t, u_register_t
1493 Return : void
1494
1495This function executes with the MMU and data caches disabled. It is only called
1496by the primary CPU. This function receives four parameters which can be used
1497by the platform to pass any needed information from the Boot ROM to BL2.
1498
Dan Handley610e7e12018-03-01 18:44:00 +00001499On Arm standard platforms, this function does the following:
Roberto Vargasb1584272017-11-20 13:36:10 +00001500
1501- Initializes a UART (PL011 console), which enables access to the ``printf``
1502 family of functions in BL2.
1503
1504- Initializes the storage abstraction layer used to load further bootloader
1505 images. It is necessary to do this early on platforms with a SCP\_BL2 image,
1506 since the later ``bl2_platform_setup`` must be done after SCP\_BL2 is loaded.
1507
1508- Initializes the private variables that define the memory layout used.
1509
1510Function : bl2\_el3\_plat\_arch\_setup() [mandatory]
1511~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1512
1513::
John Tsichritzisee10e792018-06-06 09:38:10 +01001514
Roberto Vargasb1584272017-11-20 13:36:10 +00001515 Argument : void
1516 Return : void
1517
1518This function executes with the MMU and data caches disabled. It is only called
1519by the primary CPU.
1520
1521The purpose of this function is to perform any architectural initialization
1522that varies across platforms.
1523
Dan Handley610e7e12018-03-01 18:44:00 +00001524On Arm standard platforms, this function enables the MMU.
Roberto Vargasb1584272017-11-20 13:36:10 +00001525
1526Function : bl2\_el3\_plat\_prepare\_exit() [optional]
1527~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1528
1529::
John Tsichritzisee10e792018-06-06 09:38:10 +01001530
Roberto Vargasb1584272017-11-20 13:36:10 +00001531 Argument : void
1532 Return : void
1533
1534This function is called prior to exiting BL2 and run the next image.
1535It should be used to perform platform specific clean up or bookkeeping
1536operations before transferring control to the next image. This function
1537runs with MMU disabled.
1538
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001539FWU Boot Loader Stage 2 (BL2U)
1540------------------------------
1541
1542The AP Firmware Updater Configuration, BL2U, is an optional part of the FWU
1543process and is executed only by the primary CPU. BL1 passes control to BL2U at
1544``BL2U_BASE``. BL2U executes in Secure-EL1 and is responsible for:
1545
1546#. (Optional) Transfering the optional SCP\_BL2U binary image from AP secure
1547 memory to SCP RAM. BL2U uses the SCP\_BL2U ``image_info`` passed by BL1.
1548 ``SCP_BL2U_BASE`` defines the address in AP secure memory where SCP\_BL2U
1549 should be copied from. Subsequent handling of the SCP\_BL2U image is
1550 implemented by the platform specific ``bl2u_plat_handle_scp_bl2u()`` function.
1551 If ``SCP_BL2U_BASE`` is not defined then this step is not performed.
1552
1553#. Any platform specific setup required to perform the FWU process. For
Dan Handley610e7e12018-03-01 18:44:00 +00001554 example, Arm standard platforms initialize the TZC controller so that the
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001555 normal world can access DDR memory.
1556
1557The following functions must be implemented by the platform port to enable
1558BL2U to perform the tasks mentioned above.
1559
1560Function : bl2u\_early\_platform\_setup() [mandatory]
1561~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1562
1563::
1564
1565 Argument : meminfo *mem_info, void *plat_info
1566 Return : void
1567
1568This function executes with the MMU and data caches disabled. It is only
1569called by the primary CPU. The arguments to this function is the address
1570of the ``meminfo`` structure and platform specific info provided by BL1.
1571
1572The platform may copy the contents of the ``mem_info`` and ``plat_info`` into
1573private storage as the original memory may be subsequently overwritten by BL2U.
1574
Dan Handley610e7e12018-03-01 18:44:00 +00001575On Arm CSS platforms ``plat_info`` is interpreted as an ``image_info_t`` structure,
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001576to extract SCP\_BL2U image information, which is then copied into a private
1577variable.
1578
1579Function : bl2u\_plat\_arch\_setup() [mandatory]
1580~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1581
1582::
1583
1584 Argument : void
1585 Return : void
1586
1587This function executes with the MMU and data caches disabled. It is only
1588called by the primary CPU.
1589
1590The purpose of this function is to perform any architectural initialization
1591that varies across platforms, for example enabling the MMU (since the memory
1592map differs across platforms).
1593
1594Function : bl2u\_platform\_setup() [mandatory]
1595~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1596
1597::
1598
1599 Argument : void
1600 Return : void
1601
1602This function may execute with the MMU and data caches enabled if the platform
1603port does the necessary initialization in ``bl2u_plat_arch_setup()``. It is only
1604called by the primary CPU.
1605
1606The purpose of this function is to perform any platform initialization
1607specific to BL2U.
1608
Dan Handley610e7e12018-03-01 18:44:00 +00001609In Arm standard platforms, this function performs security setup, including
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001610configuration of the TrustZone controller to allow non-secure masters access
1611to most of DRAM. Part of DRAM is reserved for secure world use.
1612
1613Function : bl2u\_plat\_handle\_scp\_bl2u() [optional]
1614~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1615
1616::
1617
1618 Argument : void
1619 Return : int
1620
1621This function is used to perform any platform-specific actions required to
1622handle the SCP firmware. Typically it transfers the image into SCP memory using
1623a platform-specific protocol and waits until SCP executes it and signals to the
1624Application Processor (AP) for BL2U execution to continue.
1625
1626This function returns 0 on success, a negative error code otherwise.
1627This function is included if SCP\_BL2U\_BASE is defined.
1628
1629Boot Loader Stage 3-1 (BL31)
1630----------------------------
1631
1632During cold boot, the BL31 stage is executed only by the primary CPU. This is
1633determined in BL1 using the ``platform_is_primary_cpu()`` function. BL1 passes
1634control to BL31 at ``BL31_BASE``. During warm boot, BL31 is executed by all
1635CPUs. BL31 executes at EL3 and is responsible for:
1636
1637#. Re-initializing all architectural and platform state. Although BL1 performs
1638 some of this initialization, BL31 remains resident in EL3 and must ensure
1639 that EL3 architectural and platform state is completely initialized. It
1640 should make no assumptions about the system state when it receives control.
1641
1642#. Passing control to a normal world BL image, pre-loaded at a platform-
Soby Mathew97b1bff2018-09-27 16:46:41 +01001643 specific address by BL2. On ARM platforms, BL31 uses the ``bl_params`` list
1644 populated by BL2 in memory to do this.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001645
1646#. Providing runtime firmware services. Currently, BL31 only implements a
1647 subset of the Power State Coordination Interface (PSCI) API as a runtime
1648 service. See Section 3.3 below for details of porting the PSCI
1649 implementation.
1650
1651#. Optionally passing control to the BL32 image, pre-loaded at a platform-
1652 specific address by BL2. BL31 exports a set of apis that allow runtime
1653 services to specify the security state in which the next image should be
Soby Mathew97b1bff2018-09-27 16:46:41 +01001654 executed and run the corresponding image. On ARM platforms, BL31 uses the
1655 ``bl_params`` list populated by BL2 in memory to do this.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001656
1657If BL31 is a reset vector, It also needs to handle the reset as specified in
1658section 2.2 before the tasks described above.
1659
1660The following functions must be implemented by the platform port to enable BL31
1661to perform the above tasks.
1662
Soby Mathew97b1bff2018-09-27 16:46:41 +01001663Function : bl31\_early\_platform\_setup2() [mandatory]
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001664~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1665
1666::
1667
Soby Mathew97b1bff2018-09-27 16:46:41 +01001668 Argument : u_register_t, u_register_t, u_register_t, u_register_t
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001669 Return : void
1670
1671This function executes with the MMU and data caches disabled. It is only called
Soby Mathew97b1bff2018-09-27 16:46:41 +01001672by the primary CPU. BL2 can pass 4 arguments to BL31 and these arguments are
1673platform specific.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001674
Soby Mathew97b1bff2018-09-27 16:46:41 +01001675In Arm standard platforms, the arguments received are :
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001676
Soby Mathew97b1bff2018-09-27 16:46:41 +01001677 arg0 - The pointer to the head of `bl_params_t` list
1678 which is list of executable images following BL31,
1679
1680 arg1 - Points to load address of SOC_FW_CONFIG if present
1681
1682 arg2 - Points to load address of HW_CONFIG if present
1683
1684 arg3 - A special value to verify platform parameters from BL2 to BL31. Not
1685 used in release builds.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001686
Soby Mathew97b1bff2018-09-27 16:46:41 +01001687The function runs through the `bl_param_t` list and extracts the entry point
1688information for BL32 and BL33. It also performs the following:
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001689
1690- Initialize a UART (PL011 console), which enables access to the ``printf``
1691 family of functions in BL31.
1692
1693- Enable issuing of snoop and DVM (Distributed Virtual Memory) requests to the
1694 CCI slave interface corresponding to the cluster that includes the primary
1695 CPU.
1696
1697Function : bl31\_plat\_arch\_setup() [mandatory]
1698~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1699
1700::
1701
1702 Argument : void
1703 Return : void
1704
1705This function executes with the MMU and data caches disabled. It is only called
1706by the primary CPU.
1707
1708The purpose of this function is to perform any architectural initialization
1709that varies across platforms.
1710
Dan Handley610e7e12018-03-01 18:44:00 +00001711On Arm standard platforms, this function enables the MMU.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001712
1713Function : bl31\_platform\_setup() [mandatory]
1714~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1715
1716::
1717
1718 Argument : void
1719 Return : void
1720
1721This function may execute with the MMU and data caches enabled if the platform
1722port does the necessary initialization in ``bl31_plat_arch_setup()``. It is only
1723called by the primary CPU.
1724
1725The purpose of this function is to complete platform initialization so that both
1726BL31 runtime services and normal world software can function correctly.
1727
Dan Handley610e7e12018-03-01 18:44:00 +00001728On Arm standard platforms, this function does the following:
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001729
1730- Initialize the generic interrupt controller.
1731
1732 Depending on the GIC driver selected by the platform, the appropriate GICv2
1733 or GICv3 initialization will be done, which mainly consists of:
1734
1735 - Enable secure interrupts in the GIC CPU interface.
1736 - Disable the legacy interrupt bypass mechanism.
1737 - Configure the priority mask register to allow interrupts of all priorities
1738 to be signaled to the CPU interface.
1739 - Mark SGIs 8-15 and the other secure interrupts on the platform as secure.
1740 - Target all secure SPIs to CPU0.
1741 - Enable these secure interrupts in the GIC distributor.
1742 - Configure all other interrupts as non-secure.
1743 - Enable signaling of secure interrupts in the GIC distributor.
1744
1745- Enable system-level implementation of the generic timer counter through the
1746 memory mapped interface.
1747
1748- Grant access to the system counter timer module
1749
1750- Initialize the power controller device.
1751
1752 In particular, initialise the locks that prevent concurrent accesses to the
1753 power controller device.
1754
1755Function : bl31\_plat\_runtime\_setup() [optional]
1756~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1757
1758::
1759
1760 Argument : void
1761 Return : void
1762
1763The purpose of this function is allow the platform to perform any BL31 runtime
1764setup just prior to BL31 exit during cold boot. The default weak
Julius Werneraae9bb12017-09-18 16:49:48 -07001765implementation of this function will invoke ``console_switch_state()`` to switch
1766console output to consoles marked for use in the ``runtime`` state.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001767
Sandrine Bailleux842117d2018-05-14 14:25:47 +02001768Function : bl31\_plat\_get\_next\_image\_ep\_info() [mandatory]
1769~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001770
1771::
1772
Sandrine Bailleux842117d2018-05-14 14:25:47 +02001773 Argument : uint32_t
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001774 Return : entry_point_info *
1775
1776This function may execute with the MMU and data caches enabled if the platform
1777port does the necessary initializations in ``bl31_plat_arch_setup()``.
1778
1779This function is called by ``bl31_main()`` to retrieve information provided by
1780BL2 for the next image in the security state specified by the argument. BL31
1781uses this information to pass control to that image in the specified security
1782state. This function must return a pointer to the ``entry_point_info`` structure
1783(that was copied during ``bl31_early_platform_setup()``) if the image exists. It
1784should return NULL otherwise.
1785
Jeenu Viswambharane834ee12018-04-27 15:17:03 +01001786Function : bl31_plat_enable_mmu [optional]
1787~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1788
1789::
1790
1791 Argument : uint32_t
1792 Return : void
1793
1794This function enables the MMU. The boot code calls this function with MMU and
1795caches disabled. This function should program necessary registers to enable
1796translation, and upon return, the MMU on the calling PE must be enabled.
1797
1798The function must honor flags passed in the first argument. These flags are
1799defined by the translation library, and can be found in the file
1800``include/lib/xlat_tables/xlat_mmu_helpers.h``.
1801
1802On DynamIQ systems, this function must not use stack while enabling MMU, which
1803is how the function in xlat table library version 2 is implementated.
1804
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001805Function : plat\_get\_syscnt\_freq2() [mandatory]
1806~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1807
1808::
1809
1810 Argument : void
1811 Return : unsigned int
1812
1813This function is used by the architecture setup code to retrieve the counter
1814frequency for the CPU's generic timer. This value will be programmed into the
Dan Handley610e7e12018-03-01 18:44:00 +00001815``CNTFRQ_EL0`` register. In Arm standard platforms, it returns the base frequency
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001816of the system counter, which is retrieved from the first entry in the frequency
1817modes table.
1818
1819#define : PLAT\_PERCPU\_BAKERY\_LOCK\_SIZE [optional]
1820~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1821
1822When ``USE_COHERENT_MEM = 0``, this constant defines the total memory (in
1823bytes) aligned to the cache line boundary that should be allocated per-cpu to
1824accommodate all the bakery locks.
1825
1826If this constant is not defined when ``USE_COHERENT_MEM = 0``, the linker
1827calculates the size of the ``bakery_lock`` input section, aligns it to the
1828nearest ``CACHE_WRITEBACK_GRANULE``, multiplies it with ``PLATFORM_CORE_COUNT``
1829and stores the result in a linker symbol. This constant prevents a platform
1830from relying on the linker and provide a more efficient mechanism for
1831accessing per-cpu bakery lock information.
1832
1833If this constant is defined and its value is not equal to the value
1834calculated by the linker then a link time assertion is raised. A compile time
1835assertion is raised if the value of the constant is not aligned to the cache
1836line boundary.
1837
Jeenu Viswambharan04e3a7f2017-10-16 08:43:14 +01001838SDEI porting requirements
1839~~~~~~~~~~~~~~~~~~~~~~~~~
1840
1841The SDEI dispatcher requires the platform to provide the following macros
1842and functions, of which some are optional, and some others mandatory.
1843
1844Macros
1845......
1846
1847Macro: PLAT_SDEI_NORMAL_PRI [mandatory]
1848^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1849
1850This macro must be defined to the EL3 exception priority level associated with
1851Normal SDEI events on the platform. This must have a higher value (therefore of
1852lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
1853
1854Macro: PLAT_SDEI_CRITICAL_PRI [mandatory]
1855^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1856
1857This macro must be defined to the EL3 exception priority level associated with
1858Critical SDEI events on the platform. This must have a lower value (therefore of
1859higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
1860
Jeenu Viswambharan7af48132018-01-16 09:29:30 +00001861**Note**: SDEI exception priorities must be the lowest among Secure priorities.
1862Among the SDEI exceptions, Critical SDEI priority must be higher than Normal
1863SDEI priority.
Jeenu Viswambharan04e3a7f2017-10-16 08:43:14 +01001864
1865Functions
1866.........
1867
1868Function: int plat_sdei_validate_entry_point(uintptr_t ep) [optional]
1869^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1870
1871::
1872
1873 Argument: uintptr_t
1874 Return: int
1875
1876This function validates the address of client entry points provided for both
1877event registration and *Complete and Resume* SDEI calls. The function takes one
1878argument, which is the address of the handler the SDEI client requested to
1879register. The function must return ``0`` for successful validation, or ``-1``
1880upon failure.
1881
Dan Handley610e7e12018-03-01 18:44:00 +00001882The default implementation always returns ``0``. On Arm platforms, this function
Jeenu Viswambharan04e3a7f2017-10-16 08:43:14 +01001883is implemented to translate the entry point to physical address, and further to
1884ensure that the address is located in Non-secure DRAM.
1885
1886Function: void plat_sdei_handle_masked_trigger(uint64_t mpidr, unsigned int intr) [optional]
1887^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1888
1889::
1890
1891 Argument: uint64_t
1892 Argument: unsigned int
1893 Return: void
1894
1895SDEI specification requires that a PE comes out of reset with the events masked.
1896The client therefore is expected to call ``PE_UNMASK`` to unmask SDEI events on
1897the PE. No SDEI events can be dispatched until such time.
1898
1899Should a PE receive an interrupt that was bound to an SDEI event while the
1900events are masked on the PE, the dispatcher implementation invokes the function
1901``plat_sdei_handle_masked_trigger``. The MPIDR of the PE that received the
1902interrupt and the interrupt ID are passed as parameters.
1903
1904The default implementation only prints out a warning message.
1905
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001906Power State Coordination Interface (in BL31)
1907--------------------------------------------
1908
Dan Handley610e7e12018-03-01 18:44:00 +00001909The TF-A implementation of the PSCI API is based around the concept of a
1910*power domain*. A *power domain* is a CPU or a logical group of CPUs which
1911share some state on which power management operations can be performed as
1912specified by `PSCI`_. Each CPU in the system is assigned a cpu index which is
1913a unique number between ``0`` and ``PLATFORM_CORE_COUNT - 1``. The
1914*power domains* are arranged in a hierarchical tree structure and each
1915*power domain* can be identified in a system by the cpu index of any CPU that
1916is part of that domain and a *power domain level*. A processing element (for
1917example, a CPU) is at level 0. If the *power domain* node above a CPU is a
1918logical grouping of CPUs that share some state, then level 1 is that group of
1919CPUs (for example, a cluster), and level 2 is a group of clusters (for
1920example, the system). More details on the power domain topology and its
Douglas Raillardd7c21b72017-06-28 15:23:03 +01001921organization can be found in `Power Domain Topology Design`_.
1922
1923BL31's platform initialization code exports a pointer to the platform-specific
1924power management operations required for the PSCI implementation to function
1925correctly. This information is populated in the ``plat_psci_ops`` structure. The
1926PSCI implementation calls members of the ``plat_psci_ops`` structure for performing
1927power management operations on the power domains. For example, the target
1928CPU is specified by its ``MPIDR`` in a PSCI ``CPU_ON`` call. The ``pwr_domain_on()``
1929handler (if present) is called for the CPU power domain.
1930
1931The ``power-state`` parameter of a PSCI ``CPU_SUSPEND`` call can be used to
1932describe composite power states specific to a platform. The PSCI implementation
1933defines a generic representation of the power-state parameter viz which is an
1934array of local power states where each index corresponds to a power domain
1935level. Each entry contains the local power state the power domain at that power
1936level could enter. It depends on the ``validate_power_state()`` handler to
1937convert the power-state parameter (possibly encoding a composite power state)
1938passed in a PSCI ``CPU_SUSPEND`` call to this representation.
1939
1940The following functions form part of platform port of PSCI functionality.
1941
1942Function : plat\_psci\_stat\_accounting\_start() [optional]
1943~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1944
1945::
1946
1947 Argument : const psci_power_state_t *
1948 Return : void
1949
1950This is an optional hook that platforms can implement for residency statistics
1951accounting before entering a low power state. The ``pwr_domain_state`` field of
1952``state_info`` (first argument) can be inspected if stat accounting is done
1953differently at CPU level versus higher levels. As an example, if the element at
1954index 0 (CPU power level) in the ``pwr_domain_state`` array indicates a power down
1955state, special hardware logic may be programmed in order to keep track of the
1956residency statistics. For higher levels (array indices > 0), the residency
1957statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
1958default implementation will use PMF to capture timestamps.
1959
1960Function : plat\_psci\_stat\_accounting\_stop() [optional]
1961~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1962
1963::
1964
1965 Argument : const psci_power_state_t *
1966 Return : void
1967
1968This is an optional hook that platforms can implement for residency statistics
1969accounting after exiting from a low power state. The ``pwr_domain_state`` field
1970of ``state_info`` (first argument) can be inspected if stat accounting is done
1971differently at CPU level versus higher levels. As an example, if the element at
1972index 0 (CPU power level) in the ``pwr_domain_state`` array indicates a power down
1973state, special hardware logic may be programmed in order to keep track of the
1974residency statistics. For higher levels (array indices > 0), the residency
1975statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
1976default implementation will use PMF to capture timestamps.
1977
1978Function : plat\_psci\_stat\_get\_residency() [optional]
1979~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1980
1981::
1982
1983 Argument : unsigned int, const psci_power_state_t *, int
1984 Return : u_register_t
1985
1986This is an optional interface that is is invoked after resuming from a low power
1987state and provides the time spent resident in that low power state by the power
1988domain at a particular power domain level. When a CPU wakes up from suspend,
1989all its parent power domain levels are also woken up. The generic PSCI code
1990invokes this function for each parent power domain that is resumed and it
1991identified by the ``lvl`` (first argument) parameter. The ``state_info`` (second
1992argument) describes the low power state that the power domain has resumed from.
1993The current CPU is the first CPU in the power domain to resume from the low
1994power state and the ``last_cpu_idx`` (third parameter) is the index of the last
1995CPU in the power domain to suspend and may be needed to calculate the residency
1996for that power domain.
1997
1998Function : plat\_get\_target\_pwr\_state() [optional]
1999~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2000
2001::
2002
2003 Argument : unsigned int, const plat_local_state_t *, unsigned int
2004 Return : plat_local_state_t
2005
2006The PSCI generic code uses this function to let the platform participate in
2007state coordination during a power management operation. The function is passed
2008a pointer to an array of platform specific local power state ``states`` (second
2009argument) which contains the requested power state for each CPU at a particular
2010power domain level ``lvl`` (first argument) within the power domain. The function
2011is expected to traverse this array of upto ``ncpus`` (third argument) and return
2012a coordinated target power state by the comparing all the requested power
2013states. The target power state should not be deeper than any of the requested
2014power states.
2015
2016A weak definition of this API is provided by default wherein it assumes
2017that the platform assigns a local state value in order of increasing depth
2018of the power state i.e. for two power states X & Y, if X < Y
2019then X represents a shallower power state than Y. As a result, the
2020coordinated target local power state for a power domain will be the minimum
2021of the requested local power state values.
2022
2023Function : plat\_get\_power\_domain\_tree\_desc() [mandatory]
2024~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025
2026::
2027
2028 Argument : void
2029 Return : const unsigned char *
2030
2031This function returns a pointer to the byte array containing the power domain
2032topology tree description. The format and method to construct this array are
2033described in `Power Domain Topology Design`_. The BL31 PSCI initilization code
2034requires this array to be described by the platform, either statically or
2035dynamically, to initialize the power domain topology tree. In case the array
2036is populated dynamically, then plat\_core\_pos\_by\_mpidr() and
2037plat\_my\_core\_pos() should also be implemented suitably so that the topology
2038tree description matches the CPU indices returned by these APIs. These APIs
2039together form the platform interface for the PSCI topology framework.
2040
2041Function : plat\_setup\_psci\_ops() [mandatory]
Douglas Raillard0929f092017-08-02 14:44:42 +01002042~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002043
2044::
2045
2046 Argument : uintptr_t, const plat_psci_ops **
2047 Return : int
2048
2049This function may execute with the MMU and data caches enabled if the platform
2050port does the necessary initializations in ``bl31_plat_arch_setup()``. It is only
2051called by the primary CPU.
2052
2053This function is called by PSCI initialization code. Its purpose is to let
2054the platform layer know about the warm boot entrypoint through the
2055``sec_entrypoint`` (first argument) and to export handler routines for
2056platform-specific psci power management actions by populating the passed
2057pointer with a pointer to BL31's private ``plat_psci_ops`` structure.
2058
2059A description of each member of this structure is given below. Please refer to
Dan Handley610e7e12018-03-01 18:44:00 +00002060the Arm FVP specific implementation of these handlers in
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002061`plat/arm/board/fvp/fvp\_pm.c`_ as an example. For each PSCI function that the
2062platform wants to support, the associated operation or operations in this
2063structure must be provided and implemented (Refer section 4 of
Dan Handley610e7e12018-03-01 18:44:00 +00002064`Firmware Design`_ for the PSCI API supported in TF-A). To disable a PSCI
2065function in a platform port, the operation should be removed from this
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002066structure instead of providing an empty implementation.
2067
2068plat\_psci\_ops.cpu\_standby()
Douglas Raillard0929f092017-08-02 14:44:42 +01002069..............................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002070
2071Perform the platform-specific actions to enter the standby state for a cpu
2072indicated by the passed argument. This provides a fast path for CPU standby
2073wherein overheads of PSCI state management and lock acquistion is avoided.
2074For this handler to be invoked by the PSCI ``CPU_SUSPEND`` API implementation,
2075the suspend state type specified in the ``power-state`` parameter should be
2076STANDBY and the target power domain level specified should be the CPU. The
2077handler should put the CPU into a low power retention state (usually by
2078issuing a wfi instruction) and ensure that it can be woken up from that
2079state by a normal interrupt. The generic code expects the handler to succeed.
2080
2081plat\_psci\_ops.pwr\_domain\_on()
Douglas Raillard0929f092017-08-02 14:44:42 +01002082.................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002083
2084Perform the platform specific actions to power on a CPU, specified
2085by the ``MPIDR`` (first argument). The generic code expects the platform to
2086return PSCI\_E\_SUCCESS on success or PSCI\_E\_INTERN\_FAIL for any failure.
2087
2088plat\_psci\_ops.pwr\_domain\_off()
Douglas Raillard0929f092017-08-02 14:44:42 +01002089..................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002090
2091Perform the platform specific actions to prepare to power off the calling CPU
2092and its higher parent power domain levels as indicated by the ``target_state``
2093(first argument). It is called by the PSCI ``CPU_OFF`` API implementation.
2094
2095The ``target_state`` encodes the platform coordinated target local power states
2096for the CPU power domain and its parent power domain levels. The handler
2097needs to perform power management operation corresponding to the local state
2098at each power level.
2099
2100For this handler, the local power state for the CPU power domain will be a
2101power down state where as it could be either power down, retention or run state
2102for the higher power domain levels depending on the result of state
2103coordination. The generic code expects the handler to succeed.
2104
Varun Wadekarae87f4b2017-07-10 16:02:05 -07002105plat\_psci\_ops.pwr\_domain\_suspend\_pwrdown\_early() [optional]
Douglas Raillard0929f092017-08-02 14:44:42 +01002106.................................................................
Varun Wadekarae87f4b2017-07-10 16:02:05 -07002107
2108This optional function may be used as a performance optimization to replace
2109or complement pwr_domain_suspend() on some platforms. Its calling semantics
2110are identical to pwr_domain_suspend(), except the PSCI implementation only
2111calls this function when suspending to a power down state, and it guarantees
2112that data caches are enabled.
2113
2114When HW_ASSISTED_COHERENCY = 0, the PSCI implementation disables data caches
2115before calling pwr_domain_suspend(). If the target_state corresponds to a
2116power down state and it is safe to perform some or all of the platform
2117specific actions in that function with data caches enabled, it may be more
2118efficient to move those actions to this function. When HW_ASSISTED_COHERENCY
2119= 1, data caches remain enabled throughout, and so there is no advantage to
2120moving platform specific actions to this function.
2121
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002122plat\_psci\_ops.pwr\_domain\_suspend()
Douglas Raillard0929f092017-08-02 14:44:42 +01002123......................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002124
2125Perform the platform specific actions to prepare to suspend the calling
2126CPU and its higher parent power domain levels as indicated by the
2127``target_state`` (first argument). It is called by the PSCI ``CPU_SUSPEND``
2128API implementation.
2129
2130The ``target_state`` has a similar meaning as described in
2131the ``pwr_domain_off()`` operation. It encodes the platform coordinated
2132target local power states for the CPU power domain and its parent
2133power domain levels. The handler needs to perform power management operation
2134corresponding to the local state at each power level. The generic code
2135expects the handler to succeed.
2136
Douglas Raillarda84996b2017-08-02 16:57:32 +01002137The difference between turning a power domain off versus suspending it is that
2138in the former case, the power domain is expected to re-initialize its state
2139when it is next powered on (see ``pwr_domain_on_finish()``). In the latter
2140case, the power domain is expected to save enough state so that it can resume
2141execution by restoring this state when its powered on (see
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002142``pwr_domain_suspend_finish()``).
2143
Douglas Raillarda84996b2017-08-02 16:57:32 +01002144When suspending a core, the platform can also choose to power off the GICv3
2145Redistributor and ITS through an implementation-defined sequence. To achieve
2146this safely, the ITS context must be saved first. The architectural part is
2147implemented by the ``gicv3_its_save_disable()`` helper, but most of the needed
2148sequence is implementation defined and it is therefore the responsibility of
2149the platform code to implement the necessary sequence. Then the GIC
2150Redistributor context can be saved using the ``gicv3_rdistif_save()`` helper.
2151Powering off the Redistributor requires the implementation to support it and it
2152is the responsibility of the platform code to execute the right implementation
2153defined sequence.
2154
2155When a system suspend is requested, the platform can also make use of the
2156``gicv3_distif_save()`` helper to save the context of the GIC Distributor after
2157it has saved the context of the Redistributors and ITS of all the cores in the
2158system. The context of the Distributor can be large and may require it to be
2159allocated in a special area if it cannot fit in the platform's global static
2160data, for example in DRAM. The Distributor can then be powered down using an
2161implementation-defined sequence.
2162
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002163plat\_psci\_ops.pwr\_domain\_pwr\_down\_wfi()
Douglas Raillard0929f092017-08-02 14:44:42 +01002164.............................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002165
2166This is an optional function and, if implemented, is expected to perform
2167platform specific actions including the ``wfi`` invocation which allows the
2168CPU to powerdown. Since this function is invoked outside the PSCI locks,
2169the actions performed in this hook must be local to the CPU or the platform
2170must ensure that races between multiple CPUs cannot occur.
2171
2172The ``target_state`` has a similar meaning as described in the ``pwr_domain_off()``
2173operation and it encodes the platform coordinated target local power states for
2174the CPU power domain and its parent power domain levels. This function must
2175not return back to the caller.
2176
2177If this function is not implemented by the platform, PSCI generic
2178implementation invokes ``psci_power_down_wfi()`` for power down.
2179
2180plat\_psci\_ops.pwr\_domain\_on\_finish()
Douglas Raillard0929f092017-08-02 14:44:42 +01002181.........................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002182
2183This function is called by the PSCI implementation after the calling CPU is
2184powered on and released from reset in response to an earlier PSCI ``CPU_ON`` call.
2185It performs the platform-specific setup required to initialize enough state for
2186this CPU to enter the normal world and also provide secure runtime firmware
2187services.
2188
2189The ``target_state`` (first argument) is the prior state of the power domains
2190immediately before the CPU was turned on. It indicates which power domains
2191above the CPU might require initialization due to having previously been in
2192low power states. The generic code expects the handler to succeed.
2193
2194plat\_psci\_ops.pwr\_domain\_suspend\_finish()
Douglas Raillard0929f092017-08-02 14:44:42 +01002195..............................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002196
2197This function is called by the PSCI implementation after the calling CPU is
2198powered on and released from reset in response to an asynchronous wakeup
2199event, for example a timer interrupt that was programmed by the CPU during the
2200``CPU_SUSPEND`` call or ``SYSTEM_SUSPEND`` call. It performs the platform-specific
2201setup required to restore the saved state for this CPU to resume execution
2202in the normal world and also provide secure runtime firmware services.
2203
2204The ``target_state`` (first argument) has a similar meaning as described in
2205the ``pwr_domain_on_finish()`` operation. The generic code expects the platform
2206to succeed.
2207
Douglas Raillarda84996b2017-08-02 16:57:32 +01002208If the Distributor, Redistributors or ITS have been powered off as part of a
2209suspend, their context must be restored in this function in the reverse order
2210to how they were saved during suspend sequence.
2211
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002212plat\_psci\_ops.system\_off()
Douglas Raillard0929f092017-08-02 14:44:42 +01002213.............................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002214
2215This function is called by PSCI implementation in response to a ``SYSTEM_OFF``
2216call. It performs the platform-specific system poweroff sequence after
2217notifying the Secure Payload Dispatcher.
2218
2219plat\_psci\_ops.system\_reset()
Douglas Raillard0929f092017-08-02 14:44:42 +01002220...............................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002221
2222This function is called by PSCI implementation in response to a ``SYSTEM_RESET``
2223call. It performs the platform-specific system reset sequence after
2224notifying the Secure Payload Dispatcher.
2225
2226plat\_psci\_ops.validate\_power\_state()
Douglas Raillard0929f092017-08-02 14:44:42 +01002227........................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002228
2229This function is called by the PSCI implementation during the ``CPU_SUSPEND``
2230call to validate the ``power_state`` parameter of the PSCI API and if valid,
2231populate it in ``req_state`` (second argument) array as power domain level
2232specific local states. If the ``power_state`` is invalid, the platform must
2233return PSCI\_E\_INVALID\_PARAMS as error, which is propagated back to the
2234normal world PSCI client.
2235
2236plat\_psci\_ops.validate\_ns\_entrypoint()
Douglas Raillard0929f092017-08-02 14:44:42 +01002237..........................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002238
2239This function is called by the PSCI implementation during the ``CPU_SUSPEND``,
2240``SYSTEM_SUSPEND`` and ``CPU_ON`` calls to validate the non-secure ``entry_point``
2241parameter passed by the normal world. If the ``entry_point`` is invalid,
2242the platform must return PSCI\_E\_INVALID\_ADDRESS as error, which is
2243propagated back to the normal world PSCI client.
2244
2245plat\_psci\_ops.get\_sys\_suspend\_power\_state()
Douglas Raillard0929f092017-08-02 14:44:42 +01002246.................................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002247
2248This function is called by the PSCI implementation during the ``SYSTEM_SUSPEND``
2249call to get the ``req_state`` parameter from platform which encodes the power
2250domain level specific local states to suspend to system affinity level. The
2251``req_state`` will be utilized to do the PSCI state coordination and
2252``pwr_domain_suspend()`` will be invoked with the coordinated target state to
2253enter system suspend.
2254
2255plat\_psci\_ops.get\_pwr\_lvl\_state\_idx()
Douglas Raillard0929f092017-08-02 14:44:42 +01002256...........................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002257
2258This is an optional function and, if implemented, is invoked by the PSCI
2259implementation to convert the ``local_state`` (first argument) at a specified
2260``pwr_lvl`` (second argument) to an index between 0 and
2261``PLAT_MAX_PWR_LVL_STATES`` - 1. This function is only needed if the platform
2262supports more than two local power states at each power domain level, that is
2263``PLAT_MAX_PWR_LVL_STATES`` is greater than 2, and needs to account for these
2264local power states.
2265
2266plat\_psci\_ops.translate\_power\_state\_by\_mpidr()
Douglas Raillard0929f092017-08-02 14:44:42 +01002267....................................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002268
2269This is an optional function and, if implemented, verifies the ``power_state``
2270(second argument) parameter of the PSCI API corresponding to a target power
2271domain. The target power domain is identified by using both ``MPIDR`` (first
2272argument) and the power domain level encoded in ``power_state``. The power domain
2273level specific local states are to be extracted from ``power_state`` and be
2274populated in the ``output_state`` (third argument) array. The functionality
2275is similar to the ``validate_power_state`` function described above and is
2276envisaged to be used in case the validity of ``power_state`` depend on the
2277targeted power domain. If the ``power_state`` is invalid for the targeted power
2278domain, the platform must return PSCI\_E\_INVALID\_PARAMS as error. If this
2279function is not implemented, then the generic implementation relies on
2280``validate_power_state`` function to translate the ``power_state``.
2281
2282This function can also be used in case the platform wants to support local
2283power state encoding for ``power_state`` parameter of PSCI\_STAT\_COUNT/RESIDENCY
2284APIs as described in Section 5.18 of `PSCI`_.
2285
2286plat\_psci\_ops.get\_node\_hw\_state()
Douglas Raillard0929f092017-08-02 14:44:42 +01002287......................................
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002288
2289This is an optional function. If implemented this function is intended to return
2290the power state of a node (identified by the first parameter, the ``MPIDR``) in
2291the power domain topology (identified by the second parameter, ``power_level``),
2292as retrieved from a power controller or equivalent component on the platform.
2293Upon successful completion, the implementation must map and return the final
2294status among ``HW_ON``, ``HW_OFF`` or ``HW_STANDBY``. Upon encountering failures, it
2295must return either ``PSCI_E_INVALID_PARAMS`` or ``PSCI_E_NOT_SUPPORTED`` as
2296appropriate.
2297
2298Implementations are not expected to handle ``power_levels`` greater than
2299``PLAT_MAX_PWR_LVL``.
2300
Roberto Vargasd963e3e2017-09-12 10:28:35 +01002301plat\_psci\_ops.system\_reset2()
2302................................
2303
2304This is an optional function. If implemented this function is
2305called during the ``SYSTEM_RESET2`` call to perform a reset
2306based on the first parameter ``reset_type`` as specified in
2307`PSCI`_. The parameter ``cookie`` can be used to pass additional
2308reset information. If the ``reset_type`` is not supported, the
2309function must return ``PSCI_E_NOT_SUPPORTED``. For architectural
2310resets, all failures must return ``PSCI_E_INVALID_PARAMETERS``
2311and vendor reset can return other PSCI error codes as defined
2312in `PSCI`_. On success this function will not return.
2313
2314plat\_psci\_ops.write\_mem\_protect()
2315....................................
2316
2317This is an optional function. If implemented it enables or disables the
2318``MEM_PROTECT`` functionality based on the value of ``val``.
2319A non-zero value enables ``MEM_PROTECT`` and a value of zero
2320disables it. Upon encountering failures it must return a negative value
2321and on success it must return 0.
2322
2323plat\_psci\_ops.read\_mem\_protect()
2324.....................................
2325
2326This is an optional function. If implemented it returns the current
2327state of ``MEM_PROTECT`` via the ``val`` parameter. Upon encountering
2328failures it must return a negative value and on success it must
2329return 0.
2330
2331plat\_psci\_ops.mem\_protect\_chk()
2332...................................
2333
2334This is an optional function. If implemented it checks if a memory
2335region defined by a base address ``base`` and with a size of ``length``
2336bytes is protected by ``MEM_PROTECT``. If the region is protected
2337then it must return 0, otherwise it must return a negative number.
2338
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002339Interrupt Management framework (in BL31)
2340----------------------------------------
2341
2342BL31 implements an Interrupt Management Framework (IMF) to manage interrupts
2343generated in either security state and targeted to EL1 or EL2 in the non-secure
2344state or EL3/S-EL1 in the secure state. The design of this framework is
2345described in the `IMF Design Guide`_
2346
2347A platform should export the following APIs to support the IMF. The following
Dan Handley610e7e12018-03-01 18:44:00 +00002348text briefly describes each api and its implementation in Arm standard
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002349platforms. The API implementation depends upon the type of interrupt controller
Dan Handley610e7e12018-03-01 18:44:00 +00002350present in the platform. Arm standard platform layer supports both
2351`Arm Generic Interrupt Controller version 2.0 (GICv2)`_
2352and `3.0 (GICv3)`_. Juno builds the Arm platform layer to use GICv2 and the
2353FVP can be configured to use either GICv2 or GICv3 depending on the build flag
2354``FVP_USE_GIC_DRIVER`` (See FVP platform specific build options in
2355`User Guide`_ for more details).
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002356
Jeenu Viswambharanb1e957e2017-09-22 08:32:09 +01002357See also: `Interrupt Controller Abstraction APIs`__.
2358
2359.. __: platform-interrupt-controller-API.rst
2360
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002361Function : plat\_interrupt\_type\_to\_line() [mandatory]
2362~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2363
2364::
2365
2366 Argument : uint32_t, uint32_t
2367 Return : uint32_t
2368
Dan Handley610e7e12018-03-01 18:44:00 +00002369The Arm processor signals an interrupt exception either through the IRQ or FIQ
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002370interrupt line. The specific line that is signaled depends on how the interrupt
2371controller (IC) reports different interrupt types from an execution context in
2372either security state. The IMF uses this API to determine which interrupt line
2373the platform IC uses to signal each type of interrupt supported by the framework
2374from a given security state. This API must be invoked at EL3.
2375
2376The first parameter will be one of the ``INTR_TYPE_*`` values (see
2377`IMF Design Guide`_) indicating the target type of the interrupt, the second parameter is the
2378security state of the originating execution context. The return result is the
2379bit position in the ``SCR_EL3`` register of the respective interrupt trap: IRQ=1,
2380FIQ=2.
2381
Dan Handley610e7e12018-03-01 18:44:00 +00002382In the case of Arm standard platforms using GICv2, S-EL1 interrupts are
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002383configured as FIQs and Non-secure interrupts as IRQs from either security
2384state.
2385
Dan Handley610e7e12018-03-01 18:44:00 +00002386In the case of Arm standard platforms using GICv3, the interrupt line to be
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002387configured depends on the security state of the execution context when the
2388interrupt is signalled and are as follows:
2389
2390- The S-EL1 interrupts are signaled as IRQ in S-EL0/1 context and as FIQ in
2391 NS-EL0/1/2 context.
2392- The Non secure interrupts are signaled as FIQ in S-EL0/1 context and as IRQ
2393 in the NS-EL0/1/2 context.
2394- The EL3 interrupts are signaled as FIQ in both S-EL0/1 and NS-EL0/1/2
2395 context.
2396
2397Function : plat\_ic\_get\_pending\_interrupt\_type() [mandatory]
2398~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2399
2400::
2401
2402 Argument : void
2403 Return : uint32_t
2404
2405This API returns the type of the highest priority pending interrupt at the
2406platform IC. The IMF uses the interrupt type to retrieve the corresponding
2407handler function. ``INTR_TYPE_INVAL`` is returned when there is no interrupt
2408pending. The valid interrupt types that can be returned are ``INTR_TYPE_EL3``,
2409``INTR_TYPE_S_EL1`` and ``INTR_TYPE_NS``. This API must be invoked at EL3.
2410
Dan Handley610e7e12018-03-01 18:44:00 +00002411In the case of Arm standard platforms using GICv2, the *Highest Priority
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002412Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of
2413the pending interrupt. The type of interrupt depends upon the id value as
2414follows.
2415
2416#. id < 1022 is reported as a S-EL1 interrupt
2417#. id = 1022 is reported as a Non-secure interrupt.
2418#. id = 1023 is reported as an invalid interrupt type.
2419
Dan Handley610e7e12018-03-01 18:44:00 +00002420In the case of Arm standard platforms using GICv3, the system register
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002421``ICC_HPPIR0_EL1``, *Highest Priority Pending group 0 Interrupt Register*,
2422is read to determine the id of the pending interrupt. The type of interrupt
2423depends upon the id value as follows.
2424
2425#. id = ``PENDING_G1S_INTID`` (1020) is reported as a S-EL1 interrupt
2426#. id = ``PENDING_G1NS_INTID`` (1021) is reported as a Non-secure interrupt.
2427#. id = ``GIC_SPURIOUS_INTERRUPT`` (1023) is reported as an invalid interrupt type.
2428#. All other interrupt id's are reported as EL3 interrupt.
2429
2430Function : plat\_ic\_get\_pending\_interrupt\_id() [mandatory]
2431~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2432
2433::
2434
2435 Argument : void
2436 Return : uint32_t
2437
2438This API returns the id of the highest priority pending interrupt at the
2439platform IC. ``INTR_ID_UNAVAILABLE`` is returned when there is no interrupt
2440pending.
2441
Dan Handley610e7e12018-03-01 18:44:00 +00002442In the case of Arm standard platforms using GICv2, the *Highest Priority
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002443Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of the
2444pending interrupt. The id that is returned by API depends upon the value of
2445the id read from the interrupt controller as follows.
2446
2447#. id < 1022. id is returned as is.
2448#. id = 1022. The *Aliased Highest Priority Pending Interrupt Register*
2449 (``GICC_AHPPIR``) is read to determine the id of the non-secure interrupt.
2450 This id is returned by the API.
2451#. id = 1023. ``INTR_ID_UNAVAILABLE`` is returned.
2452
Dan Handley610e7e12018-03-01 18:44:00 +00002453In the case of Arm standard platforms using GICv3, if the API is invoked from
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002454EL3, the system register ``ICC_HPPIR0_EL1``, *Highest Priority Pending Interrupt
2455group 0 Register*, is read to determine the id of the pending interrupt. The id
2456that is returned by API depends upon the value of the id read from the
2457interrupt controller as follows.
2458
2459#. id < ``PENDING_G1S_INTID`` (1020). id is returned as is.
2460#. id = ``PENDING_G1S_INTID`` (1020) or ``PENDING_G1NS_INTID`` (1021). The system
2461 register ``ICC_HPPIR1_EL1``, *Highest Priority Pending Interrupt group 1
2462 Register* is read to determine the id of the group 1 interrupt. This id
2463 is returned by the API as long as it is a valid interrupt id
2464#. If the id is any of the special interrupt identifiers,
2465 ``INTR_ID_UNAVAILABLE`` is returned.
2466
2467When the API invoked from S-EL1 for GICv3 systems, the id read from system
2468register ``ICC_HPPIR1_EL1``, *Highest Priority Pending group 1 Interrupt
2469Register*, is returned if is not equal to GIC\_SPURIOUS\_INTERRUPT (1023) else
2470``INTR_ID_UNAVAILABLE`` is returned.
2471
2472Function : plat\_ic\_acknowledge\_interrupt() [mandatory]
2473~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2474
2475::
2476
2477 Argument : void
2478 Return : uint32_t
2479
2480This API is used by the CPU to indicate to the platform IC that processing of
Jeenu Viswambharan055af4b2017-10-24 15:13:59 +01002481the highest pending interrupt has begun. It should return the raw, unmodified
2482value obtained from the interrupt controller when acknowledging an interrupt.
2483The actual interrupt number shall be extracted from this raw value using the API
2484`plat_ic_get_interrupt_id()`__.
2485
2486.. __: platform-interrupt-controller-API.rst#function-unsigned-int-plat-ic-get-interrupt-id-unsigned-int-raw-optional
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002487
Dan Handley610e7e12018-03-01 18:44:00 +00002488This function in Arm standard platforms using GICv2, reads the *Interrupt
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002489Acknowledge Register* (``GICC_IAR``). This changes the state of the highest
2490priority pending interrupt from pending to active in the interrupt controller.
Jeenu Viswambharan055af4b2017-10-24 15:13:59 +01002491It returns the value read from the ``GICC_IAR``, unmodified.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002492
Dan Handley610e7e12018-03-01 18:44:00 +00002493In the case of Arm standard platforms using GICv3, if the API is invoked
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002494from EL3, the function reads the system register ``ICC_IAR0_EL1``, *Interrupt
2495Acknowledge Register group 0*. If the API is invoked from S-EL1, the function
2496reads the system register ``ICC_IAR1_EL1``, *Interrupt Acknowledge Register
2497group 1*. The read changes the state of the highest pending interrupt from
2498pending to active in the interrupt controller. The value read is returned
Jeenu Viswambharan055af4b2017-10-24 15:13:59 +01002499unmodified.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002500
2501The TSP uses this API to start processing of the secure physical timer
2502interrupt.
2503
2504Function : plat\_ic\_end\_of\_interrupt() [mandatory]
2505~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2506
2507::
2508
2509 Argument : uint32_t
2510 Return : void
2511
2512This API is used by the CPU to indicate to the platform IC that processing of
2513the interrupt corresponding to the id (passed as the parameter) has
2514finished. The id should be the same as the id returned by the
2515``plat_ic_acknowledge_interrupt()`` API.
2516
Dan Handley610e7e12018-03-01 18:44:00 +00002517Arm standard platforms write the id to the *End of Interrupt Register*
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002518(``GICC_EOIR``) in case of GICv2, and to ``ICC_EOIR0_EL1`` or ``ICC_EOIR1_EL1``
2519system register in case of GICv3 depending on where the API is invoked from,
2520EL3 or S-EL1. This deactivates the corresponding interrupt in the interrupt
2521controller.
2522
2523The TSP uses this API to finish processing of the secure physical timer
2524interrupt.
2525
2526Function : plat\_ic\_get\_interrupt\_type() [mandatory]
2527~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2528
2529::
2530
2531 Argument : uint32_t
2532 Return : uint32_t
2533
2534This API returns the type of the interrupt id passed as the parameter.
2535``INTR_TYPE_INVAL`` is returned if the id is invalid. If the id is valid, a valid
2536interrupt type (one of ``INTR_TYPE_EL3``, ``INTR_TYPE_S_EL1`` and ``INTR_TYPE_NS``) is
2537returned depending upon how the interrupt has been configured by the platform
2538IC. This API must be invoked at EL3.
2539
Dan Handley610e7e12018-03-01 18:44:00 +00002540Arm standard platforms using GICv2 configures S-EL1 interrupts as Group0 interrupts
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002541and Non-secure interrupts as Group1 interrupts. It reads the group value
2542corresponding to the interrupt id from the relevant *Interrupt Group Register*
2543(``GICD_IGROUPRn``). It uses the group value to determine the type of interrupt.
2544
Dan Handley610e7e12018-03-01 18:44:00 +00002545In the case of Arm standard platforms using GICv3, both the *Interrupt Group
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002546Register* (``GICD_IGROUPRn``) and *Interrupt Group Modifier Register*
2547(``GICD_IGRPMODRn``) is read to figure out whether the interrupt is configured
2548as Group 0 secure interrupt, Group 1 secure interrupt or Group 1 NS interrupt.
2549
2550Crash Reporting mechanism (in BL31)
2551-----------------------------------
2552
Julius Werneraae9bb12017-09-18 16:49:48 -07002553NOTE: This section assumes that your platform is enabling the MULTI_CONSOLE_API
2554flag in its platform.mk. Not using this flag is deprecated for new platforms.
2555
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002556BL31 implements a crash reporting mechanism which prints the various registers
Julius Werneraae9bb12017-09-18 16:49:48 -07002557of the CPU to enable quick crash analysis and debugging. By default, the
2558definitions in ``plat/common/aarch64/platform\_helpers.S`` will cause the crash
2559output to be routed over the normal console infrastructure and get printed on
2560consoles configured to output in crash state. ``console_set_scope()`` can be
2561used to control whether a console is used for crash output.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002562
Julius Werneraae9bb12017-09-18 16:49:48 -07002563In some cases (such as debugging very early crashes that happen before the
2564normal boot console can be set up), platforms may want to control crash output
2565more explicitly. For these, the following functions can be overridden by
2566platform code. They are executed outside of a C environment and without a stack.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002567
2568Function : plat\_crash\_console\_init
2569~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2570
2571::
2572
2573 Argument : void
2574 Return : int
2575
2576This API is used by the crash reporting mechanism to initialize the crash
Julius Werneraae9bb12017-09-18 16:49:48 -07002577console. It must only use the general purpose registers x0 through x7 to do the
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002578initialization and returns 1 on success.
2579
Julius Werneraae9bb12017-09-18 16:49:48 -07002580If you are trying to debug crashes before the console driver would normally get
2581registered, you can use this to register a driver from assembly with hardcoded
2582parameters. For example, you could register the 16550 driver like this:
2583
2584::
2585
2586 .section .data.crash_console /* Reserve space for console structure */
2587 crash_console:
2588 .zero 6 * 8 /* console_16550_t has 6 8-byte words */
2589 func plat_crash_console_init
2590 ldr x0, =YOUR_16550_BASE_ADDR
2591 ldr x1, =YOUR_16550_SRCCLK_IN_HZ
2592 ldr x2, =YOUR_16550_TARGET_BAUD_RATE
2593 adrp x3, crash_console
2594 add x3, x3, :lo12:crash_console
2595 b console_16550_register /* tail call, returns 1 on success */
2596 endfunc plat_crash_console_init
2597
2598If you're trying to debug crashes in BL1, you can call the console_xxx_core_init
2599function exported by some console drivers from here.
2600
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002601Function : plat\_crash\_console\_putc
2602~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2603
2604::
2605
2606 Argument : int
2607 Return : int
2608
2609This API is used by the crash reporting mechanism to print a character on the
2610designated crash console. It must only use general purpose registers x1 and
2611x2 to do its work. The parameter and the return value are in general purpose
2612register x0.
2613
Julius Werneraae9bb12017-09-18 16:49:48 -07002614If you have registered a normal console driver in ``plat_crash_console_init``,
2615you can keep the default implementation here (which calls ``console_putc()``).
2616
2617If you're trying to debug crashes in BL1, you can call the console_xxx_core_putc
2618function exported by some console drivers from here.
2619
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002620Function : plat\_crash\_console\_flush
2621~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2622
2623::
2624
2625 Argument : void
2626 Return : int
2627
2628This API is used by the crash reporting mechanism to force write of all buffered
2629data on the designated crash console. It should only use general purpose
Julius Werneraae9bb12017-09-18 16:49:48 -07002630registers x0 through x5 to do its work. The return value is 0 on successful
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002631completion; otherwise the return value is -1.
2632
Julius Werneraae9bb12017-09-18 16:49:48 -07002633If you have registered a normal console driver in ``plat_crash_console_init``,
2634you can keep the default implementation here (which calls ``console_flush()``).
2635
2636If you're trying to debug crashes in BL1, you can call the console_xx_core_flush
2637function exported by some console drivers from here.
2638
Jeenu Viswambharanbf235bc2018-07-12 10:00:01 +01002639Extternal Abort handling and RAS Support
2640----------------------------------------
2641
2642Function : plat_ea_handler
2643~~~~~~~~~~~~~~~~~~~~~~~~~~
2644
2645::
2646
2647 Argument : int
2648 Argument : uint64_t
2649 Argument : void *
2650 Argument : void *
2651 Argument : uint64_t
2652 Return : void
2653
2654This function is invoked by the RAS framework for the platform to handle an
2655External Abort received at EL3. The intention of the function is to attempt to
2656resolve the cause of External Abort and return; if that's not possible, to
2657initiate orderly shutdown of the system.
2658
2659The first parameter (``int ea_reason``) indicates the reason for External Abort.
2660Its value is one of ``ERROR_EA_*`` constants defined in ``ea_handle.h``.
2661
2662The second parameter (``uint64_t syndrome``) is the respective syndrome
2663presented to EL3 after having received the External Abort. Depending on the
2664nature of the abort (as can be inferred from the ``ea_reason`` parameter), this
2665can be the content of either ``ESR_EL3`` or ``DISR_EL1``.
2666
2667The third parameter (``void *cookie``) is unused for now. The fourth parameter
2668(``void *handle``) is a pointer to the preempted context. The fifth parameter
2669(``uint64_t flags``) indicates the preempted security state. These parameters
2670are received from the top-level exception handler.
2671
2672If ``RAS_EXTENSION`` is set to ``1``, the default implementation of this
2673function iterates through RAS handlers registered by the platform. If any of the
2674RAS handlers resolve the External Abort, no further action is taken.
2675
2676If ``RAS_EXTENSION`` is set to ``0``, or if none of the platform RAS handlers
2677could resolve the External Abort, the default implementation prints an error
2678message, and panics.
2679
2680Function : plat_handle_uncontainable_ea
2681~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2682
2683::
2684
2685 Argument : int
2686 Argument : uint64_t
2687 Return : void
2688
2689This function is invoked by the RAS framework when an External Abort of
2690Uncontainable type is received at EL3. Due to the critical nature of
2691Uncontainable errors, the intention of this function is to initiate orderly
2692shutdown of the system, and is not expected to return.
2693
2694This function must be implemented in assembly.
2695
2696The first and second parameters are the same as that of ``plat_ea_handler``.
2697
2698The default implementation of this function calls
2699``report_unhandled_exception``.
2700
2701Function : plat_handle_double_fault
2702~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2703
2704::
2705
2706 Argument : int
2707 Argument : uint64_t
2708 Return : void
2709
2710This function is invoked by the RAS framework when another External Abort is
2711received at EL3 while one is already being handled. I.e., a call to
2712``plat_ea_handler`` is outstanding. Due to its critical nature, the intention of
2713this function is to initiate orderly shutdown of the system, and is not expected
2714recover or return.
2715
2716This function must be implemented in assembly.
2717
2718The first and second parameters are the same as that of ``plat_ea_handler``.
2719
2720The default implementation of this function calls
2721``report_unhandled_exception``.
2722
2723Function : plat_handle_el3_ea
2724~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2725
2726::
2727
2728 Return : void
2729
2730This function is invoked when an External Abort is received while executing in
2731EL3. Due to its critical nature, the intention of this function is to initiate
2732orderly shutdown of the system, and is not expected recover or return.
2733
2734This function must be implemented in assembly.
2735
2736The default implementation of this function calls
2737``report_unhandled_exception``.
2738
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002739Build flags
2740-----------
2741
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002742There are some build flags which can be defined by the platform to control
2743inclusion or exclusion of certain BL stages from the FIP image. These flags
2744need to be defined in the platform makefile which will get included by the
2745build system.
2746
2747- **NEED\_BL33**
2748 By default, this flag is defined ``yes`` by the build system and ``BL33``
2749 build option should be supplied as a build option. The platform has the
2750 option of excluding the BL33 image in the ``fip`` image by defining this flag
2751 to ``no``. If any of the options ``EL3_PAYLOAD_BASE`` or ``PRELOADED_BL33_BASE``
2752 are used, this flag will be set to ``no`` automatically.
2753
2754C Library
2755---------
2756
2757To avoid subtle toolchain behavioral dependencies, the header files provided
2758by the compiler are not used. The software is built with the ``-nostdinc`` flag
2759to ensure no headers are included from the toolchain inadvertently. Instead the
Dan Handley610e7e12018-03-01 18:44:00 +00002760required headers are included in the TF-A source tree. The library only
2761contains those C library definitions required by the local implementation. If
2762more functionality is required, the needed library functions will need to be
2763added to the local implementation.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002764
Antonio Nino Diazcf0f8052018-08-17 10:45:47 +01002765Some C headers have been obtained from `FreeBSD`_ and `SCC`_, while others have
2766been written specifically for TF-A. Fome implementation files have been obtained
2767from `FreeBSD`_, others have been written specifically for TF-A as well. The
2768files can be found in ``include/lib/libc`` and ``lib/libc``.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002769
Antonio Nino Diazcf0f8052018-08-17 10:45:47 +01002770SCC can be found in `http://www.simple-cc.org/`_. A copy of the `FreeBSD`_
2771sources can be obtained from `http://github.com/freebsd/freebsd`_.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002772
2773Storage abstraction layer
2774-------------------------
2775
2776In order to improve platform independence and portability an storage abstraction
2777layer is used to load data from non-volatile platform storage.
2778
2779Each platform should register devices and their drivers via the Storage layer.
2780These drivers then need to be initialized by bootloader phases as
2781required in their respective ``blx_platform_setup()`` functions. Currently
2782storage access is only required by BL1 and BL2 phases. The ``load_image()``
2783function uses the storage layer to access non-volatile platform storage.
2784
Dan Handley610e7e12018-03-01 18:44:00 +00002785It is mandatory to implement at least one storage driver. For the Arm
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002786development platforms the Firmware Image Package (FIP) driver is provided as
2787the default means to load data from storage (see the "Firmware Image Package"
2788section in the `User Guide`_). The storage layer is described in the header file
2789``include/drivers/io/io_storage.h``. The implementation of the common library
2790is in ``drivers/io/io_storage.c`` and the driver files are located in
2791``drivers/io/``.
2792
2793Each IO driver must provide ``io_dev_*`` structures, as described in
2794``drivers/io/io_driver.h``. These are returned via a mandatory registration
2795function that is called on platform initialization. The semi-hosting driver
2796implementation in ``io_semihosting.c`` can be used as an example.
2797
2798The Storage layer provides mechanisms to initialize storage devices before
2799IO operations are called. The basic operations supported by the layer
2800include ``open()``, ``close()``, ``read()``, ``write()``, ``size()`` and ``seek()``.
2801Drivers do not have to implement all operations, but each platform must
2802provide at least one driver for a device capable of supporting generic
2803operations such as loading a bootloader image.
2804
2805The current implementation only allows for known images to be loaded by the
2806firmware. These images are specified by using their identifiers, as defined in
2807[include/plat/common/platform\_def.h] (or a separate header file included from
2808there). The platform layer (``plat_get_image_source()``) then returns a reference
2809to a device and a driver-specific ``spec`` which will be understood by the driver
2810to allow access to the image data.
2811
2812The layer is designed in such a way that is it possible to chain drivers with
2813other drivers. For example, file-system drivers may be implemented on top of
2814physical block devices, both represented by IO devices with corresponding
2815drivers. In such a case, the file-system "binding" with the block device may
2816be deferred until the file-system device is initialised.
2817
2818The abstraction currently depends on structures being statically allocated
2819by the drivers and callers, as the system does not yet provide a means of
2820dynamically allocating memory. This may also have the affect of limiting the
2821amount of open resources per driver.
2822
2823--------------
2824
Dan Handley610e7e12018-03-01 18:44:00 +00002825*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.*
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002826
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002827.. _include/plat/common/platform.h: ../include/plat/common/platform.h
2828.. _include/plat/arm/common/plat\_arm.h: ../include/plat/arm/common/plat_arm.h%5D
2829.. _User Guide: user-guide.rst
2830.. _include/plat/common/common\_def.h: ../include/plat/common/common_def.h
2831.. _include/plat/arm/common/arm\_def.h: ../include/plat/arm/common/arm_def.h
2832.. _plat/common/aarch64/platform\_mp\_stack.S: ../plat/common/aarch64/platform_mp_stack.S
2833.. _plat/common/aarch64/platform\_up\_stack.S: ../plat/common/aarch64/platform_up_stack.S
2834.. _For example, define the build flag in platform.mk: PLAT_PL061_MAX_GPIOS%20:=%20160
2835.. _Power Domain Topology Design: psci-pd-tree.rst
2836.. _include/common/bl\_common.h: ../include/common/bl_common.h
2837.. _include/lib/aarch32/arch.h: ../include/lib/aarch32/arch.h
2838.. _Firmware Design: firmware-design.rst
2839.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
2840.. _plat/arm/board/fvp/fvp\_pm.c: ../plat/arm/board/fvp/fvp_pm.c
Soby Mathewf1e6c492018-10-02 14:01:03 +01002841.. _Platform compatibility policy: ./platform-compatibility-policy.rst
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002842.. _IMF Design Guide: interrupt-framework-design.rst
Dan Handley610e7e12018-03-01 18:44:00 +00002843.. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html
Douglas Raillardd7c21b72017-06-28 15:23:03 +01002844.. _3.0 (GICv3): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0069b/index.html
2845.. _FreeBSD: http://www.freebsd.org
Antonio Nino Diazcf0f8052018-08-17 10:45:47 +01002846.. _SCC: http://www.simple-cc.org/