Lines Matching refs:to
7 Porting Trusted Firmware-A (TF-A) to a new platform involves making some
17 implementation of variables and functions to fulfill the optional requirements.
18 These implementations are all weakly defined; they are provided to ease the
22 Some modifications are common to all Boot Loader (BL) stages. Section 2
26 Please refer to the :ref:`Platform Compatibility Policy` for the policy
33 want to use any of the functionality present in ``plat/arm`` files, please
34 create a pull request that moves the code to ``plat/common`` so that it can be
41 each BL stage to correctly port the firmware stack. They are categorized as
51 provided to help in this setup.
55 I/O addresses to reduce their virtual address space. All other addresses
56 corresponding to code and data must currently use an identity mapping.
59 parts of the code assume that is the case. It is not possible to switch to
67 block of identity mapped secure memory with Device-nGnRE attributes aligned to
71 possible for the firmware to place variables in it using the following C code
85 used to allocate any data structures that are accessed both when a CPU is
90 for the firmware to work correctly.
101 likely to be suitable for all platform ports.
115 Defines the normal stack memory available to each CPU. This constant is used
138 This macro is used by the PSCI implementation to allocate
139 data structures to represent power domain topology.
144 should apply to. More often, but not always, the power domain level
145 corresponds to affinity level. This macro allows the PSCI implementation
146 to know the highest power domain level that it should consider for power
153 Defines the local power state corresponding to the deepest power down
157 value to initialize the local power states of the power domain nodes and
158 to specify the requested power state for a PSCI_CPU_OFF call.
162 Defines the local power state corresponding to the deepest retention state
165 PSCI implementation to distinguish between retention and power down local
173 power domain level (power-down and retention). If the platform needs to
176 Currently, this macro is used by the Generic PSCI implementation to size
203 when BL2_IN_XIP_MEM is set to '1'.
208 This constant is not applicable when BL2_IN_XIP_MEM is set to '1'.
214 when BL2_IN_XIP_MEM is set to '1'.
220 constant is only needed when BL2_IN_XIP_MEM is set to '1'.
226 needed when BL2_IN_XIP_MEM is set to '1'.
232 to '1'.
244 used by BL1 or BL2 to load the corresponding image into memory from non-volatile
246 identifiers. The platform will use those identifiers to return the relevant
247 information about the image to be loaded (file handler, load address,
253 BL2 image identifier, used by BL1 to load BL2.
257 BL31 image identifier, used by BL2 to load BL31.
261 BL33 image identifier, used by BL2 to load BL33.
268 BL2 content certificate identifier, used by BL1 to load the BL2 content
273 Trusted key certificate identifier, used by BL2 to load the trusted key
278 BL31 key certificate identifier, used by BL2 to load the BL31 key
283 BL31 content certificate identifier, used by BL2 to load the BL31 content
288 BL33 key certificate identifier, used by BL2 to load the BL33 key
293 BL33 content certificate identifier, used by BL2 to load the BL33 content
298 Firmware Update (FWU) certificate identifier, used by NS_BL1U to load the
322 BL2U image identifier, used by BL1 to fetch an image descriptor
323 corresponding to BL2U.
330 SCP_BL2U image identifier, used by BL1 to fetch an image descriptor
331 corresponding to SCP_BL2U.
349 NS_BL1U image identifier, used by BL1 to fetch an image descriptor
350 corresponding to NS_BL1U.
365 NS_BL2U image identifier, used by BL1 to fetch an image descriptor
366 corresponding to NS_BL2U.
374 doesn't specify any value, it defaults to 10.
381 SCP_BL2 image identifier, used by BL2 to load SCP_BL2 into secure memory
382 from platform storage before being transferred to the SCP.
386 SCP_BL2 key certificate identifier, used by BL2 to load the SCP_BL2 key
391 SCP_BL2 content certificate identifier, used by BL2 to load the SCP_BL2
399 BL32 image identifier, used by BL2 to load BL32.
403 BL32 key certificate identifier, used by BL2 to load the BL32 key
408 BL32 content certificate identifier, used by BL2 to load the BL32 content
445 Optional flag that can be set per-image to enable the dynamic allocation of
447 functionality will be available, if defined and set to 1 it will also
454 used, choose the smallest value needed to map the required virtual addresses
456 image, ``MAX_XLAT_TABLES`` must be defined to accommodate the dynamic regions
467 runtime memory used, choose the smallest value needed to register the
469 enabled for a BL image, ``MAX_MMAP_REGIONS`` must be defined to accommodate
487 Defines the maximum number of registered IO devices. Attempting to register
493 Defines the maximum number of open IO handles. Attempting to open more IO
498 Defines the maximum number of registered IO block devices. Attempting to
504 If the platform needs to allocate data within the per-cpu data framework in
506 the platform decides not to use the coherent memory section by undefining the
508 required memory within the the per-cpu data to minimize wastage.
512 Defines the memory (in bytes) to be reserved within the per-cpu data
554 The following constant is optional. It should be defined to override the default
555 behaviour of the ``assert()`` function (for example, to save memory).
562 doesn't print anything to the console. If ``PLAT_LOG_LEVEL_ASSERT`` isn't
563 defined, it defaults to ``LOG_LEVEL``.
583 This macro allows the crash reporting routine to print relevant platform
585 and this macro can be defined to be empty in case register reporting is not
604 performs the necessary steps to remove it from this state.
606 #. In the case of a warm boot, ensuring that the CPU jumps to a platform-
610 The following functions need to be implemented by the platform port to enable
611 reset vector code to perform the above tasks.
625 reset entrypoint point provided to ``plat_setup_psci_ops()`` during
630 not assume that callee saved registers are preserved across a call to this
637 both on a cold and warm reset. In this case, there is no need to identify the
638 type of reset nor to query the warm reset entrypoint. Therefore, implementing
650 primary CPU performs the necessary actions to bring it out of that state and
679 primary CPU will execute the cold boot code. Therefore, there is no need to
691 This function is called before any access to data is made by the firmware, in
692 order to carry out any essential memory initialization.
703 pointer to the ROTPK stored in the platform (or a hash of it) and its length.
704 The ROTPK must be encoded in DER format according to the following ASN.1
730 to the ROTPK in the flags parameter:
736 ROTPK_NOT_DEPLOYED : This allows the platform to skip certificate ROTPK
738 When this flag is set, the function does not need to
754 cookie in the first argument may be used to select the counter in case the
756 TBBR CoT, the cookie will correspond to the OID values defined in
771 counter value in the platform. The cookie in the first argument may be used to
773 the updated counter value to be written to the NV counter.
788 first argument passed is a cookie and is typically used to
790 Counter. The second argument is a pointer to an authentication image
791 descriptor and may be used to decide if the counter is allowed to be
792 updated or not. The third argument is the updated counter value to
793 be written to the NV counter.
797 that it is not allowed to be updated.
802 The following functions are mandatory functions which need to be implemented
833 This function validates the ``MPIDR`` of a CPU and converts it to an index,
838 represents the power domain topology and how this relates to the linear CPU
849 This function is invoked during Mbed TLS library initialisation to get a heap,
852 must be able to provide a heap to it.
858 For a platform to use this default implementation, only a call to the helper
861 However, by writting their own implementation, platforms have the potential to
882 trying to implement a real world firmware encryption use-case.
884 It also allows the platform to pass symmetric key identifier rather than
889 In addition to above a platform may also choose to provide an image specific
906 It provides a means to retrieve image specification (offset in
913 In Arm platforms, this function is used to set an I/O policy of the FIP image,
928 be used to load this image from the platform's non-volatile storage.
931 to define its image specification (offset in non-volatile storage and length)
935 that needs to be parsed dynamically.
936 This function provides a means to retrieve such dynamic information to set
949 common platform-specific tasks. A platform may choose to override these
960 This function sets the current stack pointer to the normal memory stack that
963 of the stack allocated to each CPU is specified by the platform defined
981 of the stack allocated to each CPU is specified by the platform defined
996 A platform may need to report various information about its status when an
1004 The default implementation doesn't do anything, to avoid making assumptions
1010 related to any architectural exception code; they are just a TF-A convention.
1024 A platform may need to do additional initialization after reset. This function
1025 allows the platform to do the platform specific initializations. Platform
1027 preserve the values of callee saved registers x19 to x29.
1029 The default implementation doesn't do anything. If a platform needs to override
1030 the default implementation, refer to the :ref:`Firmware Design` for general
1041 This API allows a platform to disable the Accelerator Coherency Port (if
1046 by the caller to store the return address.
1057 which it cannot continue. It allows the platform to perform error reporting or
1097 This function returns pointer to the list of images that the platform has
1098 populated to load. This function is invoked in BL2 to load the
1109 This function returns a pointer to the shared memory that the platform has
1110 kept aside to pass TF-A related information that next BL image needs. This
1111 function is invoked in BL2 to pass this information to the next BL
1122 This function returns a random value that is used to initialize the canary used
1129 For the protection to be effective, the global data need to be placed at
1130 a lower address than the stack bases. Failure to do so would allow an
1131 attacker to overwrite the canary as part of the stack buffer overflow attack.
1141 This function flushes to main memory all the image params that are passed to
1142 next image. This function is invoked in BL2 to flush this information
1143 to the next BL image.
1153 This function defines the prefix string corresponding to the `log_level` to be
1154 prepended to all the log output from TF-A. The `log_level` (argument) will
1155 correspond to one of the standard log levels defined in debug.h. The platform
1156 can override the common implementation to define a different prefix string for
1157 the log output. The implementation should be robust to future changes that
1202 Modifications specific to a Boot Loader stage
1215 control to the BL2 stage.
1227 meminfo.total_base = Base address of secure RAM visible to BL2
1228 meminfo.total_size = Size of secure RAM visible to BL2
1231 memory visible to BL2.
1233 It is possible for the platform to decide where it wants to place the
1234 ``meminfo`` structure for BL2 or restrict the amount of memory visible to
1238 The following functions need to be implemented by the platform port to enable
1239 BL1 to perform the above tasks.
1254 - Enables a secure instance of SP805 to act as the Trusted Watchdog.
1256 - Initializes a UART (PL011 console), which enables access to the ``printf``
1259 - Enables issuing of snoop and DVM (Distributed Virtual Memory) requests to
1260 the CCI slave interface corresponding to the cluster that includes the
1295 layer used to load the next bootloader image.
1308 MMU and data caches enabled. The pointer returned by this function must point to
1314 meminfo.total_base = Base address of secure RAM visible to BL1
1315 meminfo.total_size = Size of secure RAM visible to BL1
1317 This information is used by BL1 to load the BL2 image in secure RAM. BL1 also
1318 populates a similar structure to tell BL2 the extents of memory available for
1331 This function is called prior to exiting BL1 in response to the
1332 ``BL1_SMC_RUN_IMAGE`` SMC request raised by BL2. It should be used to perform
1334 control to the next image. It receives the address of the ``entry_point_info_t``
1345 This function allows platforms to override ``ep_info`` for the given ``image_id``.
1357 This and the following function must be overridden to enable the FWU feature.
1359 BL1 calls this function after platform setup to identify the next image to be
1365 platforms override this function to detect if firmware update is required, and
1376 BL1 calls this function to get the image descriptor information ``image_desc_t``
1380 standard platforms return an image descriptor corresponding to BL2 or one of
1392 This function can be used by the platforms to update/use image information
1393 corresponding to ``image_id``. This function is invoked in BL1, both in cold
1404 This function can be used by the platforms to update/use image information
1405 corresponding to ``image_id``. This function is invoked in BL1, both in cold
1412 information to BL2.
1424 The platform may override this function to take platform specific action, for
1425 example to initiate the normal boot flow.
1439 copying or authenticating an image. Its responsibility is to ensure that the
1441 that this memory corresponds to either a secure or non-secure memory region as
1457 using the ``platform_is_primary_cpu()`` function. BL1 passed control to BL2 at
1459 ``plat_get_bl_image_load_info()`` to retrieve the list of images to load from
1460 non-volatile storage to secure/non-secure RAM. After all the images are loaded
1461 then BL2 invokes ``plat_get_next_bl_params()`` to get the list of executable
1462 images to be passed to the next BL image.
1464 The following functions must be implemented by the platform port to enable BL2
1465 to perform the above tasks.
1476 by the primary CPU. The 4 arguments are passed by BL1 to BL2 and these arguments
1481 arg0 - Points to load address of FW_CONFIG
1488 - Initializes a UART (PL011 console), which enables access to the ``printf``
1491 - Initializes the storage abstraction layer used to load further bootloader
1492 images. It is necessary to do this early on platforms with a SCP_BL2 image,
1506 The purpose of this function is to perform any architectural initialization
1523 The purpose of this function is to perform any platform initialization
1524 specific to BL2.
1527 configuration of the TrustZone controller to allow non-secure masters access
1528 to most of DRAM. Part of DRAM is reserved for secure world use.
1538 This function can be used by the platforms to update/use image information
1550 This function can be used by the platforms to update/use image information
1576 This optional function passes to the next boot source in the redundancy
1579 This function moves the current boot redundancy source to the next
1587 When the platform has a non-TF-A Boot ROM it is desirable to jump
1588 directly to BL2 instead of TF-A BL1. In this case BL2 is expected to
1589 execute at EL3 instead of executing at EL1. Refer to the :ref:`Firmware Design`
1609 by the platform to pass any needed information from the Boot ROM to BL2.
1613 - Initializes a UART (PL011 console), which enables access to the ``printf``
1616 - Initializes the storage abstraction layer used to load further bootloader
1617 images. It is necessary to do this early on platforms with a SCP_BL2 image,
1633 The purpose of this function is to perform any architectural initialization
1646 This function is called prior to exiting BL2 and run the next image.
1647 It should be used to perform platform specific clean up or bookkeeping
1648 operations before transferring control to the next image. This function
1655 process and is executed only by the primary CPU. BL1 passes control to BL2U at
1659 memory to SCP RAM. BL2U uses the SCP_BL2U ``image_info`` passed by BL1.
1665 #. Any platform specific setup required to perform the FWU process. For
1669 The following functions must be implemented by the platform port to enable
1670 BL2U to perform the tasks mentioned above.
1681 called by the primary CPU. The arguments to this function is the address
1688 to extract SCP_BL2U image information, which is then copied into a private
1702 The purpose of this function is to perform any architectural initialization
1718 The purpose of this function is to perform any platform initialization
1719 specific to BL2U.
1722 configuration of the TrustZone controller to allow non-secure masters access
1723 to most of DRAM. Part of DRAM is reserved for secure world use.
1733 This function is used to perform any platform-specific actions required to
1735 a platform-specific protocol and waits until SCP executes it and signals to the
1736 Application Processor (AP) for BL2U execution to continue.
1746 control to BL31 at ``BL31_BASE``. During warm boot, BL31 is executed by all
1754 #. Passing control to a normal world BL image, pre-loaded at a platform-
1756 populated by BL2 in memory to do this.
1763 #. Optionally passing control to the BL32 image, pre-loaded at a platform-
1765 services to specify the security state in which the next image should be
1767 ``bl_params`` list populated by BL2 in memory to do this.
1769 If BL31 is a reset vector, It also needs to handle the reset as specified in
1772 The following functions must be implemented by the platform port to enable BL31
1773 to perform the above tasks.
1784 by the primary CPU. BL2 can pass 4 arguments to BL31 and these arguments are
1789 arg0 - The pointer to the head of `bl_params_t` list
1792 arg1 - Points to load address of SOC_FW_CONFIG if present
1795 In case of Arm FVP and Juno platform, points to load address
1798 arg2 - Points to load address of HW_CONFIG if present
1800 arg3 - A special value to verify platform parameters from BL2 to BL31. Not
1806 - Initialize a UART (PL011 console), which enables access to the ``printf``
1809 - Enable issuing of snoop and DVM (Distributed Virtual Memory) requests to the
1810 CCI slave interface corresponding to the cluster that includes the primary
1824 The purpose of this function is to perform any architectural initialization
1841 The purpose of this function is to complete platform initialization so that both
1853 - Configure the priority mask register to allow interrupts of all priorities
1854 to be signaled to the CPU interface.
1856 - Target all secure SPIs to CPU0.
1864 - Grant access to the system counter timer module
1868 In particular, initialise the locks that prevent concurrent accesses to the
1879 The purpose of this function is allow the platform to perform any BL31 runtime
1880 setup just prior to BL31 exit during cold boot. The default weak
1881 implementation of this function will invoke ``console_switch_state()`` to switch
1882 console output to consoles marked for use in the ``runtime`` state.
1895 This function is called by ``bl31_main()`` to retrieve information provided by
1897 uses this information to pass control to that image in the specified security
1898 state. This function must return a pointer to the ``entry_point_info`` structure
1911 caches disabled. This function should program necessary registers to enable
1929 This function returns the 128-bit value which can be used to program ARMv8.3
1935 Trusted Firmware by building with ``BRANCH_PROTECTION`` option set to non-zero.
1945 This function is used by the architecture setup code to retrieve the counter
1959 This function is used in v8.6+ systems to set the WFE trap delay value in
1961 feature is not enabled. The only hook provided is to set the TWED fields in
1962 SCR_EL3, there are similar fields in HCR_EL2, SCTLR_EL2, and SCTLR_EL1 to adjust
1970 bytes) aligned to the cache line boundary that should be allocated per-cpu to
1974 calculates the size of the ``bakery_lock`` input section, aligns it to the
1980 If this constant is defined and its value is not equal to the value
1982 assertion is raised if the value of the constant is not aligned to the cache
1990 The |SDEI| dispatcher requires the platform to provide the following macros
1999 This macro must be defined to the EL3 exception priority level associated with
2006 This macro must be defined to the EL3 exception priority level associated with
2049 masked. The client therefore is expected to call ``PE_UNMASK`` to unmask
2053 Should a PE receive an interrupt that was bound to an |SDEI| event while the
2065 The |TRNG| backend requires the platform to provide the following values
2074 This value must be defined to the UUID of the TRNG backend that is specific to
2076 conform to the SMCCC calling convention; The most significant 32 bits of the
2078 w0 indicates failure to get a TRNG source.
2091 This function is expected to do platform-specific initialization of any TRNG
2102 storage pointed to
2124 BL31's platform initialization code exports a pointer to the platform-specific
2125 power management operations required for the PSCI implementation to function
2132 The ``power-state`` parameter of a PSCI ``CPU_SUSPEND`` call can be used to
2133 describe composite power states specific to a platform. The PSCI implementation
2135 array of local power states where each index corresponds to a power domain
2137 level could enter. It depends on the ``validate_power_state()`` handler to
2139 passed in a PSCI ``CPU_SUSPEND`` call to this representation.
2156 state, special hardware logic may be programmed in order to keep track of the
2159 default implementation will use PMF to capture timestamps.
2174 state, special hardware logic may be programmed in order to keep track of the
2177 default implementation will use PMF to capture timestamps.
2194 The current CPU is the first CPU in the power domain to resume from the low
2196 CPU in the power domain to suspend and may be needed to calculate the residency
2207 The PSCI generic code uses this function to let the platform participate in
2209 a pointer to an array of platform specific local power state ``states`` (second
2212 is expected to traverse this array of upto ``ncpus`` (third argument) and return
2232 This function returns a pointer to the byte array containing the power domain
2233 topology tree description. The format and method to construct this array are
2235 initialization code requires this array to be described by the platform, either
2236 statically or dynamically, to initialize the power domain topology tree. In case
2254 This function is called by PSCI initialization code. Its purpose is to let
2256 ``sec_entrypoint`` (first argument) and to export handler routines for
2258 pointer with a pointer to BL31's private ``plat_psci_ops`` structure.
2260 A description of each member of this structure is given below. Please refer to
2263 platform wants to support, the associated operation or operations in this
2272 Perform the platform-specific actions to enter the standby state for a cpu
2275 For this handler to be invoked by the PSCI ``CPU_SUSPEND`` API implementation,
2280 state by a normal interrupt. The generic code expects the handler to succeed.
2285 Perform the platform specific actions to power on a CPU, specified
2286 by the ``MPIDR`` (first argument). The generic code expects the platform to
2292 Perform the platform specific actions to prepare to power off the calling CPU
2298 needs to perform power management operation corresponding to the local state
2304 coordination. The generic code expects the handler to succeed.
2309 This optional function may be used as a performance optimization to replace
2311 are identical to pwr_domain_suspend(), except the PSCI implementation only
2312 calls this function when suspending to a power down state, and it guarantees
2316 before calling pwr_domain_suspend(). If the target_state corresponds to a
2317 power down state and it is safe to perform some or all of the platform
2319 efficient to move those actions to this function. When HW_ASSISTED_COHERENCY
2320 = 1, data caches remain enabled throughout, and so there is no advantage to
2321 moving platform specific actions to this function.
2326 Perform the platform specific actions to prepare to suspend the calling
2334 power domain levels. The handler needs to perform power management operation
2335 corresponding to the local state at each power level. The generic code
2336 expects the handler to succeed.
2339 in the former case, the power domain is expected to re-initialize its state
2341 case, the power domain is expected to save enough state so that it can resume
2345 When suspending a core, the platform can also choose to power off the GICv3
2350 the platform code to implement the necessary sequence. Then the GIC
2352 Powering off the Redistributor requires the implementation to support it and it
2353 is the responsibility of the platform code to execute the right implementation
2357 ``gicv3_distif_save()`` helper to save the context of the GIC Distributor after
2359 system. The context of the Distributor can be large and may require it to be
2367 This is an optional function and, if implemented, is expected to perform
2369 CPU to powerdown. Since this function is invoked outside the PSCI locks,
2370 the actions performed in this hook must be local to the CPU or the platform
2376 not return back to the caller.
2385 powered on and released from reset in response to an earlier PSCI ``CPU_ON`` call.
2386 It performs the platform-specific setup required to initialize enough state for
2387 this CPU to enter the normal world and also provide secure runtime firmware
2392 above the CPU might require initialization due to having previously been in
2393 low power states. The generic code expects the handler to succeed.
2400 the associated cluster are guaranteed to be participating in coherency. This
2401 function gives the flexibility to perform any platform-specific actions safely,
2406 operation. The generic code expects the handler to succeed.
2412 powered on and released from reset in response to an asynchronous wakeup
2415 setup required to restore the saved state for this CPU to resume execution
2420 to succeed.
2424 to how they were saved during suspend sequence.
2429 This function is called by PSCI implementation in response to a ``SYSTEM_OFF``
2436 This function is called by PSCI implementation in response to a ``SYSTEM_RESET``
2444 call to validate the ``power_state`` parameter of the PSCI API and if valid,
2447 return PSCI_E_INVALID_PARAMS as error, which is propagated back to the
2454 ``SYSTEM_SUSPEND`` and ``CPU_ON`` calls to validate the non-secure ``entry_point``
2457 propagated back to the normal world PSCI client.
2463 call to get the ``req_state`` parameter from platform which encodes the power
2464 domain level specific local states to suspend to system affinity level. The
2465 ``req_state`` will be utilized to do the PSCI state coordination and
2466 ``pwr_domain_suspend()`` will be invoked with the coordinated target state to
2473 implementation to convert the ``local_state`` (first argument) at a specified
2474 ``pwr_lvl`` (second argument) to an index between 0 and
2477 ``PLAT_MAX_PWR_LVL_STATES`` is greater than 2, and needs to account for these
2484 (second argument) parameter of the PSCI API corresponding to a target power
2487 level specific local states are to be extracted from ``power_state`` and be
2489 is similar to the ``validate_power_state`` function described above and is
2490 envisaged to be used in case the validity of ``power_state`` depend on the
2494 ``validate_power_state`` function to translate the ``power_state``.
2496 This function can also be used in case the platform wants to support local
2503 This is an optional function. If implemented this function is intended to return
2512 Implementations are not expected to handle ``power_levels`` greater than
2519 called during the ``SYSTEM_RESET2`` call to perform a reset
2521 `PSCI`_. The parameter ``cookie`` can be used to pass additional
2558 BL31 implements an Interrupt Management Framework (IMF) to manage interrupts
2559 generated in either security state and targeted to EL1 or EL2 in the non-secure
2563 A platform should export the following APIs to support the IMF. The following
2568 and `3.0 (GICv3)`_. Juno builds the Arm platform layer to use GICv2 and the
2569 FVP can be configured to use either GICv2 or GICv3 depending on the build flag
2586 either security state. The IMF uses this API to determine which interrupt line
2587 the platform IC uses to signal each type of interrupt supported by the framework
2600 In the case of Arm standard platforms using GICv3, the interrupt line to be
2620 platform IC. The IMF uses the interrupt type to retrieve the corresponding
2626 Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of
2636 is read to determine the id of the pending interrupt. The type of interrupt
2657 Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of the
2663 (``GICC_AHPPIR``) is read to determine the id of the non-secure interrupt.
2669 group 0 Register*, is read to determine the id of the pending interrupt. The id
2676 Register* is read to determine the id of the group 1 interrupt. This id
2683 Register*, is returned if is not equal to GIC_SPURIOUS_INTERRUPT (1023) else
2694 This API is used by the CPU to indicate to the platform IC that processing of
2702 priority pending interrupt from pending to active in the interrupt controller.
2710 pending to active in the interrupt controller. The value read is returned
2713 The TSP uses this API to start processing of the secure physical timer
2724 This API is used by the CPU to indicate to the platform IC that processing of
2725 the interrupt corresponding to the id (passed as the parameter) has
2729 Arm standard platforms write the id to the *End of Interrupt Register*
2730 (``GICC_EOIR``) in case of GICv2, and to ``ICC_EOIR0_EL1`` or ``ICC_EOIR1_EL1``
2735 The TSP uses this API to finish processing of the secure physical timer
2754 corresponding to the interrupt id from the relevant *Interrupt Group Register*
2755 (``GICD_IGROUPRn``). It uses the group value to determine the type of interrupt.
2759 (``GICD_IGRPMODRn``) is read to figure out whether the interrupt is configured
2766 of the CPU to enable quick crash analysis and debugging. This mechanism relies
2771 implementation of all of them. Platforms may include this file to their
2772 makefiles in order to benefit from them. By default, they will cause the crash
2773 output to be routed over the normal console infrastructure and get printed on
2774 consoles configured to output in crash state. ``console_set_scope()`` can be
2775 used to control whether a console is used for crash output.
2779 use in the crash scope that are able to support this, i.e. that are written
2784 normal boot console can be set up), platforms may want to control crash output
2788 that are designed to be used by these functions. See Arm platforms (like juno)
2799 This API is used by the crash reporting mechanism to initialize the crash
2800 console. It must only use the general purpose registers x0 through x7 to do the
2811 This API is used by the crash reporting mechanism to print a character on the
2813 x2 to do its work. The parameter and the return value are in general purpose
2824 This API is used by the crash reporting mechanism to force write of all buffered
2826 registers x0 through x5 to do its work.
2845 This function is invoked by the RAS framework for the platform to handle an
2846 External Abort received at EL3. The intention of the function is to attempt to
2847 resolve the cause of External Abort and return; if that's not possible, to
2854 presented to EL3 after having received the External Abort. Depending on the
2859 (``void *handle``) is a pointer to the preempted context. The fifth parameter
2863 If ``RAS_EXTENSION`` is set to ``1``, the default implementation of this
2867 If ``RAS_EXTENSION`` is set to ``0``, or if none of the platform RAS handlers
2881 Uncontainable type is received at EL3. Due to the critical nature of
2882 Uncontainable errors, the intention of this function is to initiate orderly
2883 shutdown of the system, and is not expected to return.
2902 received at EL3 while one is already being handled. I.e., a call to
2903 ``plat_ea_handler`` is outstanding. Due to its critical nature, the intention of
2904 this function is to initiate orderly shutdown of the system, and is not expected
2922 EL3. Due to its critical nature, the intention of this function is to initiate
2933 There are some build flags which can be defined by the platform to control
2935 need to be defined in the platform makefile which will get included by the
2942 to ``no``. If any of the options ``EL3_PAYLOAD_BASE`` or ``PRELOADED_BL33_BASE``
2943 are used, this flag will be set to ``no`` automatically.
2948 Platforms are allowed to add more include paths to be passed to the compiler.
2963 to ensure no headers are included from the toolchain inadvertently. Instead the
2966 more functionality is required, the needed library functions will need to be
2967 added to the local implementation.
2980 In order to improve platform independence and portability a storage abstraction
2981 layer is used to load data from non-volatile platform storage. Currently
2987 It is mandatory to implement at least one storage driver. For the Arm
2989 the default means to load data from storage (see :ref:`firmware_design_fip`).
3003 abstraction layer. These drivers then need to be initialized by bootloader
3008 The storage abstraction layer provides mechanisms (``io_dev_init()``) to
3015 Drivers do not have to implement all operations, but each platform must
3019 The current implementation only allows for known images to be loaded by the
3023 to a device and a driver-specific ``spec`` which will be understood by the driver
3024 to allow access to the image data.
3026 The layer is designed in such a way that is it possible to chain drivers with