Lines Matching refs:be
25 interfaces as they get introduced in the code base should be *strongly*
48 propose a patch that moves the code to ``plat/common`` so that it can be
54 This section covers the modifications that should be made by the platform for
103 The following variables, functions and constants must be defined by the platform
117 likely to be suitable for all platform ports.
171 states for each level may be sparsely allocated between 0 and this value
179 possible at every power domain level in the platform. This macro should be
197 Defines the base address in secure ROM where BL1 originally lives. Must be
208 at runtime. Must be aligned on a page-size boundary.
218 Must be aligned on a page-size boundary. This constant is not applicable
229 lives. Must be aligned on a page-size boundary. This constant is only needed
241 at runtime. Must be aligned on a page-size boundary. This constant is only
253 image. Must be aligned on a page-size boundary.
264 For every image, the platform must define individual identifiers that will be
266 storage. For the sake of performance, integer numbers will be used as
268 information about the image to be loaded (file handler, load address,
285 also be defined:
323 must also be defined:
328 image. Must be aligned on a page-size boundary.
340 must also be defined:
351 also be defined:
356 Must be aligned on a page-size boundary.
367 be defined:
372 Must be aligned on a page-size boundary.
383 macros may also be defined:
387 Total number of images that can be loaded simultaneously. If the platform
391 also be defined:
409 also be defined:
428 image. Must be aligned on a page-size boundary.
435 platform, the following constants must also be defined:
440 platform. This must be at the same address or below ``BL32_BASE``.
455 constants must also be defined:
459 Optional flag that can be set per-image to enable the dynamic allocation of
461 functionality will be available, if defined and set to 1 it will also
470 image, ``MAX_XLAT_TABLES`` must be defined to accommodate the dynamic regions
479 that should be mapped. Then, the translation table library will create the
483 enabled for a BL image, ``MAX_MMAP_REGIONS`` must be defined to accommodate
489 for a 32 bit virtual address space, this value should be ``(1ULL << 32)``.
494 for a 32 bit physical address space, this value should be ``(1ULL << 32)``.
497 must also be defined:
514 with -ENOMEM. MAX_IO_BLOCK_DEVICES should be less than MAX_IO_DEVICES.
515 With this macro, multiple block devices could be supported at the same
526 Defines the memory (in bytes) to be reserved within the per-cpu data
529 The following constants are optional. They should be defined when the platform
544 constant must be defined.
551 optionally be defined:
560 optionally be defined:
571 The size of partition block. It could be either 512 bytes or 4096 bytes.
578 configuration must be performed:
580 - The NPU SiP service handler must be hooked up. This consists of both the
585 enabled, the following constants and configuration must also be defined:
614 Defines the physical address range that the NPU's firmware will be loaded
619 firmware code and a region for protected inference data, and these must be
639 The following constant is optional. It should be defined to override the default
650 If the platform port uses the DRTM feature, the following constants must be
676 and this macro can be defined to be empty in case register reporting is not
679 For instance, GIC or interconnect registers may be helpful for
686 or warm boot. BL31 can be optionally set as a reset vector using the
701 The following functions need to be implemented by the platform port to enable
795 The ROTPK must be encoded in DER format according to the following ASN.1
833 must not be used in a deployed production environment.
845 cookie in the first argument may be used to select the counter in case the
851 not be retrieved from the platform.
862 counter value in the platform. The cookie in the first argument may be used to
864 the updated counter value to be written to the NV counter.
867 not be updated.
878 interface is defined, then ``plat_set_nv_ctr()`` need not be defined. The
882 descriptor and may be used to decide if the counter is allowed to be
884 be written to the NV counter.
887 either could not be updated or the authentication image descriptor indicates
888 that it is not allowed to be updated.
933 be trusted, and such peripherals should be moved under "Non-host platforms"
934 if they can be trusted.
1094 The following functions are mandatory functions which need to be implemented
1107 per-CPU stacks). This function will be invoked very early in the
1108 initialization sequence which mandates that this function should be
1114 PSCI and details of this can be found in
1126 which can be used as a CPU-specific linear index into blocks of memory. In
1128 be invoked by BL31 after the power domain topology is initialized and can
1142 by means of a starting address and a size. This heap will then be used
1144 must be able to provide a heap to it.
1146 A helper function can be found in `drivers/auth/mbedtls/mbedtls_common.c` in
1173 implementation for testing purposes which must be overridden by the platform
1179 flag must be set in ``flags``.
1219 be used to load this image from the platform's non-volatile storage.
1221 FWU metadata can not be always stored as a raw image in non-volatile storage
1226 that needs to be parsed dynamically.
1336 specific errata workarounds could also be implemented here. The API should
1373 - ``-EAUTH``: a certificate or image could not be authenticated (when Trusted
1375 - ``-ENOENT``: the requested image or certificate could not be found or an IO
1392 and must be implemented in assembly because it may be called before the C
1439 For the protection to be effective, the global data need to be placed at
1463 This function defines the prefix string corresponding to the `log_level` to be
1467 the log output. The implementation should be robust to future changes that
1510 must be set to point to a static, null-terminated SoC name string. The string
1511 must be encoded in UTF-8 and should use only printable ASCII characters for
1539 - This function indicates whether cache management operations should be
1540 performed. It returns 0 if CMOs should be skipped and non-zero
1549 It has to be defined in platform code and registered by calling
1573 In case PSA FWU is not used, it can be any instance or media. If PSA FWU is
1650 The following functions need to be implemented by the platform port to enable
1716 This function should only be called on the cold boot path. It executes with the
1741 ``BL1_SMC_RUN_IMAGE`` SMC request raised by BL2. It should be used to perform
1766 This and the following function must be overridden to enable the FWU feature.
1768 BL1 calls this function after platform setup to identify the next image to be
1801 This function can be used by the platforms to update/use image information
1825 This function can be used by the platforms to update/use image information
1830 Trusted SRAM that can be used by BL2 and allocates a ``meminfo_t``
1895 images to be passed to the next BL image.
1897 The following functions must be implemented by the platform port to enable BL2
1918 the contents of ``meminfo`` as it may be subsequently overwritten by BL2.
1927 since the later ``bl2_platform_setup`` must be done after SCP_BL2 is loaded.
1972 This function can be used by the platforms to update/use image information
1984 This function can be used by the platforms to update/use image information
2020 should be copied from. Subsequent handling of the SCP_BL2U image is
2028 The following functions must be implemented by the platform port to enable
2044 private storage as the original memory may be subsequently overwritten by BL2U.
2124 services to specify the security state in which the next image should be
2131 The following functions must be implemented by the platform port to enable BL31
2208 or GICv3 initialization will be done, which mainly consists of:
2213 to be signaled to the CPU interface.
2272 to this function may be needed to retrieve the entire token.
2276 arg0 - A pointer to the buffer where the Platform token should be copied by
2287 48 and 64. This argument must be zero for subsequent calls to
2291 be returned in further calls.
2304 This function returns the delegated realm attestation key which will be used to
2310 arg0 - A pointer to the buffer where the attestation key should be copied
2311 by this function. The buffer must be big enough to hold the
2359 encryption key is to be updated. The second argument specifies the reason
2364 This function needs to be implemented by a platform if it enables RME.
2374 Reserve memory to be used by the RMM. This could be memory simply taken from a pool of reserved
2378 to be aligned to ``alignment`` bytes.
2380 This function needs to be implemented if a platform enables RME and the RMM requires the memory
2392 the RMM and EL3 is modeled as a queue but the underlying implementation may be different,
2400 arg0: Pointer to the token sign request to be pushed to EL3.
2401 The structure must be located in the RMM-EL3 shared
2402 memory buffer and must be locked before use.
2408 queue in EL3 is full. This may also be returned for any reason
2424 be different, so long as the semantics of queuing and the error codes are used as defined
2433 The structure must be located in the RMM-EL3 shared
2434 memory buffer and must be locked before use.
2451 This function returns the public portion of the realm attestation key which will be used to
2453 returned, however, there may be platforms where the private key bits are better protected
2462 arg0 - A pointer to the buffer where the public key should be copied
2463 by this function. The buffer must be big enough to hold the
2487 and `cookie` are to be ignored for blocking mode and are pass-through to the response for
2492 or non-blocking semantics. More details about IDE Setup flow can be found
2506 arg4 - The request ID, is used in non-blocking mode only and can be ignored in blocking mode.
2508 arg5 - The cookie variable, is used in non-blocking mode only and can be ignored in blocking
2527 before acting on it. The arguments `request ID` and `cookie` are to be ignored for blocking
2532 or non-blocking semantics. More details about IDE Setup flow can be found
2544 arg3 - The request ID, is used in non-blocking mode only and can be ignored in blocking mode.
2546 arg4 - The cookie variable, is used in non-blocking mode only and can be ignored in blocking
2565 on it. The arguments `request ID` and `cookie` are to be ignored for blocking
2570 or non-blocking semantics. More details about IDE Setup flow can be found
2582 arg3 - The request ID, is used in non-blocking mode only and can be ignored in blocking mode.
2584 arg4 - The cookie variable, is used in non-blocking mode only and can be ignored in blocking
2607 or non-blocking semantics. More details about IDE Setup flow can be found
2642 translation, and upon return, the MMU on the calling PE must be enabled.
2645 defined by the translation library, and can be found in the file
2659 This function returns the 128-bit value which can be used to program ARMv8.3
2662 The value should be obtained from a reliable source of randomness. It will be
2678 frequency for the CPU's generic timer. This value will be programmed into the
2687 bytes) aligned to the cache line boundary that should be allocated per-cpu to
2716 This macro must be defined to the EL3 exception priority level associated with
2723 This macro must be defined to the EL3 exception priority level associated with
2727 **Note**: |SDEI| exception priorities must be the lowest among Secure
2729 be higher than Normal |SDEI| priority.
2747 can be Non-Secure EL1 or Non-Secure EL2.
2767 |SDEI| events on the PE. No |SDEI| events can be dispatched until such
2791 This value must be defined to the UUID of the TRNG backend that is specific to
2822 is available, it must return false and the storage must not be written.
2831 share some state on which power management operations can be performed as
2835 *power domain* can be identified in a system by the cpu index of any CPU that
2841 organization can be found in :ref:`PSCI Power Domain Tree Structure`.
2851 The ``power_state`` parameter of a PSCI ``CPU_SUSPEND`` call can be used to
2880 ``state_info`` (first argument) can be inspected if stat accounting is done
2883 state, special hardware logic may be programmed in order to keep track of the
2885 statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
2898 of ``state_info`` (first argument) can be inspected if stat accounting is done
2901 state, special hardware logic may be programmed in order to keep track of the
2903 statistics could be tracked in software using PMF. If ``ENABLE_PMF`` is set, the
2923 CPU in the power domain to suspend and may be needed to calculate the residency
2941 states. The target power state should not be deeper than any of the requested
2948 coordinated target local power state for a power domain will be the minimum
2962 initialization code requires this array to be described by the platform, either
2965 plat_my_core_pos() should also be implemented suitably so that the topology tree
2991 structure must be provided and implemented (Refer section 4 of
2993 function in a platform port, the operation should be removed from this
3002 For this handler to be invoked by the PSCI ``CPU_SUSPEND`` API implementation,
3003 the suspend state type specified in the ``power-state`` parameter should be
3004 STANDBY and the target power domain level specified should be the CPU. The
3006 issuing a wfi instruction) and ensure that it can be woken up from that
3026 For this handler, the local power state for the CPU power domain will be a
3027 power down state where as it could be either power down, retention or run state
3044 For this handler, the local power state for the CPU power domain will be a
3045 power down state where as it could be either power down, retention or run state
3063 This optional function may be used as a performance optimization to replace
3072 specific actions in that function with data caches enabled, it may be more
3101 this safely, the ITS context must be saved first. The architectural part is
3105 Redistributor context can be saved using the ``gicv3_rdistif_save()`` helper.
3113 system. The context of the Distributor can be large and may require it to be
3115 data, for example in DRAM. The Distributor can then be powered down using an
3123 invoked outside the PSCI locks, the actions performed in this hook must be local
3135 possible on platforms where this is guaranteed to be terminal, however, it is
3160 the associated cluster are guaranteed to be participating in coherency. This
3183 suspend, their context must be restored in this function in the reverse order
3227 ``req_state`` will be utilized to do the PSCI state coordination and
3228 ``pwr_domain_suspend()`` will be invoked with the coordinated target state to
3249 level specific local states are to be extracted from ``power_state`` and be
3252 envisaged to be used in case the validity of ``power_state`` depend on the
3258 This function can also be used in case the platform wants to support local
3283 `PSCI`_. The parameter ``cookie`` can be used to pass additional
3323 ``spd_pm_ops_t`` callbacks for this purpose. These hooks must be
3329 use of secure interrupts, then these interrupts must also be managed
3331 to the current CPU must be disabled or re-targeted to other running CPU prior
3332 to power down of the current CPU. During power up, these interrupt can be
3405 FVP can be configured to use either GICv2 or GICv3 depending on the build flag
3424 from a given security state. This API must be invoked at EL3.
3426 The first parameter will be one of the ``INTR_TYPE_*`` values (see
3436 In the case of Arm standard platforms using GICv3, the interrupt line to be
3458 pending. The valid interrupt types that can be returned are ``INTR_TYPE_EL3``,
3459 ``INTR_TYPE_S_EL1`` and ``INTR_TYPE_NS``. This API must be invoked at EL3.
3533 The actual interrupt number shall be extracted from this raw value using the API
3562 finished. The id should be the same as the id returned by the
3586 IC. This API must be invoked at EL3.
3602 a console for visual data output in TF-A. These can be used for data output during
3605 The console framework can be used to output data on to a console using a number of
3606 TF-A supported UARTs. Multiple consoles can be registered at the same time with
3607 different output scopes (BOOT, RUNTIME, CRASH) so that data can be displayed on
3610 Information for registering a console can be found in the :ref:`Console Framework` section
3636 cannot be recovered from. This function assumes that it is invoked from a C
3648 be recovered from. This function in turn prints backtrace (if enabled) and calls
3662 output to be routed over the normal console infrastructure and get printed on
3663 consoles configured to output in crash state. ``console_set_scope()`` can be
3673 normal boot console can be set up), platforms may want to control crash output
3677 that are designed to be used by these functions. See Arm platforms (like juno)
3735 these functions should be able to handle being called with power domains off and
3740 Should this not be desirable, or if there is no powerdown abandon support, then
3741 RAS errors should be masked by writing any relevant error records in any
3767 nature of the abort (as can be inferred from the ``ea_reason`` parameter), this
3768 can be the content of either ``ESR_EL3`` or ``DISR_EL1``.
3775 This function must be implemented if a platform expects Firmware First handling
3792 This function must be implemented in assembly.
3814 This function must be implemented in assembly.
3832 This function must be implemented in assembly.
3857 was trapped. Its content can be changed, to put the entropy into the target
3864 to the same instruction, so its execution will be repeated.
3868 This function needs to be implemented by a platform if it enables FEAT_RNG_TRAP.
3884 {SCR,MDCR,CPTR}_PLAT_{BITS,IGNORED,FLIPPED} should be defined to report correct
3898 to the same instruction, so its execution will be repeated.
3902 This function needs to be implemented by a platform if it enables
3908 There are some build flags which can be defined by the platform to control
3910 need to be defined in the platform makefile which will get included by the
3915 build option should be supplied as a build option. The platform has the
3918 are used, this flag will be set to ``no`` automatically.
3924 version will be enabled by default and any optional Arch feature supported by
3925 the Architecture and available in TF-A can be enabled from platform specific
3932 Platforms are allowed to add more include paths to be passed to the compiler.
3950 more functionality is required, the needed library functions will need to be
3956 files can be found in ``include/lib/libc`` and ``lib/libc``.
3958 SCC can be found in http://www.simple-cc.org/. A copy of the `FreeBSD`_ sources
3959 can be obtained from http://github.com/freebsd/freebsd.
3984 implementation in ``io_semihosting.c`` can be used as an example.
3987 abstraction layer. These drivers then need to be initialized by bootloader
4003 The current implementation only allows for known images to be loaded by the
4007 to a device and a driver-specific ``spec`` which will be understood by the driver
4011 other drivers. For example, file-system drivers may be implemented on top of
4014 be deferred until the file-system device is initialised.
4080 is incomplete and the function should be called again by the caller.