Lines Matching refs:in
12 - Setting up the execution context in a certain way, or
15 The platform-specific functions and variables are declared in
23 discusses these in detail. The subsequent sections discuss the remaining
24 modifications for each BL stage in detail.
30 functions/definitions in ``include/plat/arm/common/`` and the corresponding
31 source files in ``plat/arm/common/``. This is done so that there are no
33 want to use any of the functionality present in ``plat/arm`` files, please
51 provided to help in this setup.
58 Also, the only translation granule size supported in TF-A is 4KB, as various
62 In Arm standard platforms, each BL stage configures the MMU in the
69 memory are grouped under ``coherent_ram``. For ex: Bakery locks are placed in a
71 possible for the firmware to place variables in it using the following C code
97 Each platform must ensure that a header file of this name is in the system
99 the list of ``PLAT_INCLUDES`` in the ``platform.mk`` file.
123 Defines the size in bytes of the largest cache line across all the cache
124 levels in the platform.
134 clusters in the system.
138 Defines the total number of nodes in the power domain topology
149 management operations in the system that the platform implements. For
156 possible at every power domain level in the platform. The local power
165 possible at every power domain level in the platform. This macro should be
183 Defines the base address in secure ROM where BL1 originally lives. Must be
188 Defines the maximum address in secure ROM that BL1's actual content (i.e.
193 Defines the base address in secure RAM where BL1's read-write data will live
198 Defines the maximum address in secure RAM that BL1's read-write data can
203 Defines the base address in secure RAM where BL1 loads the BL2 binary image.
209 Defines the maximum address in secure RAM that the BL2 image can occupy.
214 Defines the base address in secure XIP memory where BL2 RO section originally
220 Defines the maximum address in secure XIP memory that BL2's actual content
226 Defines the base address in secure RAM where BL2's read-write data will live
232 Defines the maximum address in secure RAM that BL2's read-write data can
238 Defines the base address in secure RAM where BL2 loads the BL31 binary
243 Defines the maximum address in secure RAM that the BL31 image can occupy.
320 Defines the base address in secure memory where BL1 copies the BL2U binary
325 Defines the maximum address in secure memory that the BL2U image can occupy.
348 Defines the base address in non-secure ROM where NS_BL1U executes.
364 Defines the base address in non-secure memory where NS_BL2U executes.
420 Defines the base address in secure memory where BL2 loads the BL32 binary
471 defined in the ``mmap_region_t`` structure. The platform defines the regions
481 Defines the total size of the virtual address space in bytes. For example,
486 Defines the total size of the physical address space in bytes. For example,
511 If the platform needs to allocate data within the per-cpu data framework in
519 Defines the memory (in bytes) to be reserved within the per-cpu data
523 memory layout implies some image overlaying like in Arm standard platforms.
527 Defines the maximum address in secure RAM that the BL31's progbits sections
550 For example, define the build flag in ``platform.mk``:
557 For example, define the build flag in ``platform.mk``:
590 Each platform must ensure a file of this name is in the system include path with
592 found in ``plat/arm/board/<plat_name>/include/plat_macros.S``.
597 registers in case of an unhandled exception in BL31. This aids in debugging
598 and this macro can be defined to be empty in case register reporting is not
616 the CPU is placed in a platform-specific state until the primary CPU
620 specific address in the BL31 image in the same processor mode as it was
662 for placing the executing secondary CPU in a platform-specific state until the
669 they stay powered on and are put in a holding pen until their mailbox gets
704 This function is called before any access to data is made by the firmware, in
716 pointer to the ROTPK stored in the platform (or a hash of it) and its length.
717 The ROTPK must be encoded in DER format according to the following ASN.1
743 to the ROTPK in the flags parameter:
753 framework uses the ROTPK in the certificate without
755 must not be used in a deployed production environment.
766 non-volatile counter value stored in the platform in the second argument. The
767 cookie in the first argument may be used to select the counter in case the
769 TBBR CoT, the cookie will correspond to the OID values defined in
784 counter value in the platform. The cookie in the first argument may be used to
785 select the counter (as explained in plat_get_nv_ctr()). The second argument is
825 be the one saved in OTP.
832 hash is saved in OTP.
840 Dynamic Root of Trust for Measurement support (in BL31)
843 The functions mentioned in this section are mandatory, when platform enables
894 This function returns the total number of SMMUs in the platform.
928 This function returns the maximum size of DMA protected regions table in
1036 per-CPU stacks). This function will be invoked very early in the
1038 implemented in assembly and should not rely on the availability of a C
1042 This function plays a crucial role in the power domain topology framework in
1043 PSCI and details of this can be found in
1075 A helper function can be found in `drivers/auth/mbedtls/mbedtls_common.c` in
1106 actual symmetric key which is useful in cases where the crypto backend provides
1107 secure storage for the symmetric key. So in this case ``ENC_KEY_IS_IDENTIFIER``
1108 flag must be set in ``flags``.
1126 It provides a means to retrieve image specification (offset in
1150 FWU metadata can not be always stored as a raw image in non-volatile storage
1151 to define its image specification (offset in non-volatile storage and length)
1152 statically in I/O policy.
1154 partition table image. Its specification is defined in the partition table
1206 provided in ``plat/common/aarch64/platform_up_stack.S`` and
1224 provided in ``plat/common/aarch64/platform_up_stack.S`` and
1238 called in the following circumstances:
1247 Possible values for exceptions types are listed in the
1252 Possible values for exception modes are listed in the
1284 scratch registers. It should preserve the value in x18 register as it is used
1321 and must be implemented in assembly because it may be called before the C
1325 The address from where it was called is stored in x30 (Link Register).
1337 in any specific use-case where system needs to be resetted. For example,
1338 in case of DRTM implementation this function reset the system after
1339 writing the DRTM error code in the non-volatile storage. This function
1340 never returns. Failure in reset results in panic.
1351 populated to load. This function is invoked in BL2 to load the
1364 function is invoked in BL2 to pass this information to the next BL
1395 next image. This function is invoked in BL2 to flush this information
1408 correspond to one of the standard log levels defined in debug.h. The platform
1437 This function returns soc revision in below format
1452 the SMCCC function specified in the argument; otherwise returns
1468 passed id and information and then records that measurement in the
1517 #. Handling the reset as described in section 2.2
1528 #. Populating a ``meminfo`` structure with the following information in memory,
1563 family of functions in BL1.
1623 This information is used by BL1 to load the BL2 image in secure RAM. BL1 also
1637 This function is called prior to exiting BL1 in response to the
1672 if so, return the first image in the firmware update process.
1687 the firmware update images defined in the Trusted Board Boot Requirements
1699 corresponding to ``image_id``. This function is invoked in BL1, both in cold
1711 corresponding to ``image_id``. This function is invoked in BL1, both in cold
1717 of ``meminfo_t`` structure is updated in ``arg1`` of the entrypoint
1746 region of memory identified by ``mem_base`` and ``mem_size`` is mapped in BL1, and
1771 backend driver, and also to write header information in the Event Log buffer.
1791 It results in panic on error.
1798 The BL2 stage is executed only by the primary CPU, which is determined in BL1
1800 ``BL2_BASE``. BL2 executes in Secure EL1 and and invokes
1831 family of functions in BL2.
1862 port does the necessary initialization in ``bl2_plat_arch_setup()``. It is only
1881 for given ``image_id``. This function is currently invoked in BL2 before
1893 for given ``image_id``. This function is currently invoked in BL2 after
1905 required before image loading, that is not done later in
1918 This optional function passes to the next boot source in the redundancy
1922 element in the boot sequence. If there are no more boot sources then it
1939 size) received from BL1. It results in panic on error.
1958 via nt_fw and tos_fw config respectively. It results in panic on error.
1992 family of functions in BL2.
2034 ``BL2U_BASE``. BL2U executes in Secure-EL1 and is responsible for:
2038 ``SCP_BL2U_BASE`` defines the address in AP secure memory where SCP_BL2U
2093 port does the necessary initialization in ``bl2u_plat_arch_setup()``. It is only
2123 determined in BL1 using the ``platform_is_primary_cpu()`` function. BL1 passes
2128 some of this initialization, BL31 remains resident in EL3 and must ensure
2134 populated by BL2 in memory to do this.
2143 services to specify the security state in which the next image should be
2145 ``bl_params`` list populated by BL2 in memory to do this.
2147 If BL31 is a reset vector, It also needs to handle the reset as specified in
2171 except in case of Arm FVP and Juno platform.
2179 used in release builds.
2185 family of functions in BL31.
2216 port does the necessary initialization in ``bl31_plat_arch_setup()``. It is only
2229 - Enable secure interrupts in the GIC CPU interface.
2235 - Enable these secure interrupts in the GIC distributor.
2237 - Enable signaling of secure interrupts in the GIC distributor.
2260 console output to consoles marked for use in the ``runtime`` state.
2271 port does the necessary initializations in ``bl31_plat_arch_setup()``.
2274 BL2 for the next image in the security state specified by the argument. BL31
2275 uses this information to pass control to that image in the specified security
2296 arg1 - Contains the size (in bytes) of the buffer passed in arg0. The
2297 function returns the platform token length in this parameter.
2301 arg3 - The length of the challenge object in bytes. Possible values are 32,
2324 arg1 - Contains the size (in bytes) of the buffer passed in arg0. The
2325 function returns the attestation key length in this parameter.
2342 in the pointer passed as argument.
2353 RMM image and stores it in the area specified by manifest.
2369 The function must honor flags passed in the first argument. These flags are
2370 defined by the translation library, and can be found in the file
2374 is how the function in xlat table library version 2 is implemented.
2389 This function is only needed if ARMv8.3 pointer authentication is used in the
2403 of the system counter, which is retrieved from the first entry in the frequency
2409 When ``USE_COHERENT_MEM = 0``, this constant defines the total memory (in
2416 and stores the result in a linker symbol. This constant prevents a platform
2467 The function ensures that the address is valid in the client translation regime.
2469 The second argument is the exception level that the client is executing in. It
2476 further ensures that the resulting physical address is located in Non-secure
2517 UUID must not equal ``0xffffffff`` or the signed integer ``-1`` as this value in
2547 Power State Coordination Interface (in BL31)
2553 specified by `PSCI`_. Each CPU in the system is assigned a cpu index which is
2555 *power domains* are arranged in a hierarchical tree structure and each
2556 *power domain* can be identified in a system by the cpu index of any CPU that
2562 organization can be found in :ref:`PSCI Power Domain Tree Structure`.
2566 correctly. This information is populated in the ``plat_psci_ops`` structure. The
2569 CPU is specified by its ``MPIDR`` in a PSCI ``CPU_ON`` call. The ``pwr_domain_on()``
2579 passed in a PSCI ``CPU_SUSPEND`` call to this representation.
2595 index 0 (CPU power level) in the ``pwr_domain_state`` array indicates a power down
2596 state, special hardware logic may be programmed in order to keep track of the
2598 statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
2613 index 0 (CPU power level) in the ``pwr_domain_state`` array indicates a power down
2614 state, special hardware logic may be programmed in order to keep track of the
2616 statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
2628 state and provides the time spent resident in that low power state by the power
2634 The current CPU is the first CPU in the power domain to resume from the low
2636 CPU in the power domain to suspend and may be needed to calculate the residency
2647 The PSCI generic code uses this function to let the platform participate in
2658 that the platform assigns a local state value in order of increasing depth
2674 described in :ref:`PSCI Power Domain Tree Structure`. The BL31 PSCI
2691 port does the necessary initializations in ``bl31_plat_arch_setup()``. It is only
2701 the Arm FVP specific implementation of these handlers in
2703 platform wants to support, the associated operation or operations in this
2705 :ref:`Firmware Design` for the PSCI API supported in TF-A). To disable a PSCI
2706 function in a platform port, the operation should be removed from this
2716 the suspend state type specified in the ``power-state`` parameter should be
2758 specific actions in that function with data caches enabled, it may be more
2771 The ``target_state`` has a similar meaning as described in
2779 in the former case, the power domain is expected to re-initialize its state
2798 it has saved the context of the Redistributors and ITS of all the cores in the
2800 allocated in a special area if it cannot fit in the platform's global static
2801 data, for example in DRAM. The Distributor can then be powered down using an
2810 the actions performed in this hook must be local to the CPU or the platform
2813 The ``target_state`` has a similar meaning as described in the ``pwr_domain_off()``
2816 not return back to the caller (by calling wfi in an infinite loop to ensure
2826 powered on and released from reset in response to an earlier PSCI ``CPU_ON`` call.
2833 above the CPU might require initialization due to having previously been in
2841 the associated cluster are guaranteed to be participating in coherency. This
2846 The ``target_state`` has a similar meaning as described in the ``pwr_domain_on_finish()``
2853 powered on and released from reset in response to an asynchronous wakeup
2857 in the normal world and also provide secure runtime firmware services.
2859 The ``target_state`` (first argument) has a similar meaning as described in
2864 suspend, their context must be restored in this function in the reverse order
2870 This function is called by PSCI implementation in response to a ``SYSTEM_OFF``
2877 This function is called by PSCI implementation in response to a ``SYSTEM_RESET``
2886 populate it in ``req_state`` (second argument) array as power domain level
2927 argument) and the power domain level encoded in ``power_state``. The power domain
2929 populated in the ``output_state`` (third argument) array. The functionality
2931 envisaged to be used in case the validity of ``power_state`` depend on the
2937 This function can also be used in case the platform wants to support local
2939 APIs as described in Section 5.18 of `PSCI`_.
2945 the power state of a node (identified by the first parameter, the ``MPIDR``) in
2961 based on the first parameter ``reset_type`` as specified in
2967 in `PSCI`_. On success this function will not return.
2996 Interrupt Management framework (in BL31)
3000 generated in either security state and targeted to EL1 or EL2 in the non-secure
3001 state or EL3/S-EL1 in the secure state. The design of this framework is
3002 described in the :ref:`Interrupt Management Framework`
3005 text briefly describes each API and its implementation in Arm standard
3007 present in the platform. Arm standard platform layer supports both
3026 controller (IC) reports different interrupt types from an execution context in
3034 execution context. The return result is the bit position in the ``SCR_EL3``
3045 - The S-EL1 interrupts are signaled as IRQ in S-EL0/1 context and as FIQ in
3047 - The Non secure interrupts are signaled as FIQ in S-EL0/1 context and as IRQ
3048 in the NS-EL0/1/2 context.
3049 - The EL3 interrupts are signaled as FIQ in both S-EL0/1 and NS-EL0/1/2
3141 This function in Arm standard platforms using GICv2, reads the *Interrupt
3143 priority pending interrupt from pending to active in the interrupt controller.
3151 pending to active in the interrupt controller. The value read is returned
3171 (``GICC_EOIR``) in case of GICv2, and to ``ICC_EOIR0_EL1`` or ``ICC_EOIR1_EL1``
3172 system register in case of GICv3 depending on where the API is invoked from,
3173 EL3 or S-EL1. This deactivates the corresponding interrupt in the interrupt
3228 be recovered from. This function in turn prints backtrace (if enabled) and calls
3231 Crash Reporting mechanism (in BL31)
3241 makefiles in order to benefit from them. By default, they will cause the crash
3243 consoles configured to output in crash state. ``console_set_scope()`` can be
3248 use in the crash scope that are able to support this, i.e. that are written
3249 in assembly and conform with the register clobber rules for putc()
3282 x2 to do its work. The parameter and the return value are in general purpose
3320 Its value is one of ``ERROR_EA_*`` constants defined in ``ea_handle.h``.
3354 This function must be implemented in assembly.
3376 This function must be implemented in assembly.
3390 This function is invoked when an External Abort is received while executing in
3394 This function must be implemented in assembly.
3404 need to be defined in the platform makefile which will get included by the
3410 option of excluding the BL33 image in the ``fip`` image by defining this flag
3418 The ``PLAT_INCLUDES`` variable is used for this purpose. This is needed in
3433 required headers are included in the TF-A source tree. The library only
3441 files can be found in ``include/lib/libc`` and ``lib/libc``.
3443 SCC can be found in http://www.simple-cc.org/. A copy of the `FreeBSD`_ sources
3452 ``load_image()`` function in ``bl_common.c``.
3459 The storage layer is described in the header file
3461 in ``drivers/io/io_storage.c`` and the driver files are located in
3466 Each IO driver must provide ``io_dev_*`` structures, as described in
3469 implementation in ``io_semihosting.c`` can be used as an example.
3473 phases as required in their respective ``blx_platform_setup()`` functions.
3489 firmware. These images are specified by using their identifiers, as defined in
3495 The layer is designed in such a way that is it possible to chain drivers with