Lines Matching refs:is
41 default implementation is inadequate.
66 If the build option `USE_COHERENT_MEM` is enabled, each platform must allocate a
68 page boundary (4K) for each BL stage. This memory is identified by the section
78 The `tzfw_coherent_mem` section is used to allocate any data structures that are
79 accessed both when a CPU is executing with its MMU and caches enabled, and when
88 Each platform must ensure that a header file of this name is in the system
91 file is found in [plat/fvp/include/platform_def.h].
105 Defines the normal stack memory available to each CPU. This constant is used
116 Name of the BL2 binary image on the host file-system. This name is used by
121 Name of the BL3-1 binary image on the host file-system. This name is used by
126 Name of the BL3-3 binary image on the host file-system. This name is used by
132 Trusted Board Boot is enabled).
137 Trusted Board Boot is enabled).
142 Trusted Board Boot is enabled).
147 when Trusted Board Boot is enabled).
152 Trusted Board Boot is enabled).
157 when Trusted Board Boot is enabled).
227 If a BL3-0 image is supported by the platform, the following constants must
232 Name of the BL3-0 binary image on the host file-system. This name is used by
239 Trusted Board Boot is enabled).
244 when Trusted Board Boot is enabled).
246 If a BL3-2 image is supported by the platform, the following constants must
251 Name of the BL3-2 binary image on the host file-system. This name is used by
257 Trusted Board Boot is enabled).
262 when Trusted Board Boot is enabled).
273 If the Test Secure-EL1 Payload (TSP) instantiation of BL3-2 is supported by the
309 BL3-1, it should define the following macro. Currently this is only required if
333 Each platform must ensure a file of this name is in the system include path with
334 the following macro defined. In the ARM FVP port, this file is found in
341 this macro can be defined to be empty in case GIC register reporting is
349 is not desired. In the ARM FVP port, the CCI snoop control registers are
360 This function is used by the architecture setup code to retrieve the
364 which is retrieved from the first entry in the frequency modes table.
374 For each CPU, the reset vector code is responsible for the following tasks:
379 the CPU is placed in a platform-specific state until the primary CPU
395 This function is called with the `SCTLR.M` and `SCTLR.C` bits disabled. The CPU
396 is identified by its `MPIDR`, which is passed as the argument. The function is
402 This function is also responsible for implementing a platform-specific mechanism
403 to handle the condition where the CPU has been warm reset but there is no
419 This function is called with the MMU and data caches disabled. It is responsible
424 In the ARM FVP port, each secondary CPU powers itself off. The primary CPU is
436 This function identifies a CPU by its `MPIDR`, which is passed as the argument,
437 to determine whether this CPU is the primary CPU or a secondary CPU. A return
438 value of zero indicates that the CPU is not the primary CPU, while a non-zero
439 return value indicates that the CPU is the primary CPU.
447 This function is called before any access to data is made by the firmware, in
459 This function is mandatory when Trusted Board Boot is enabled. It receives a
498 require a stack for the primary CPU the parameter is ignored. The size of
499 the stack allocated to each CPU is specified by the platform defined constant
514 require a stack for the primary CPU the parameter is ignored. The size of
515 the stack allocated to each CPU is specified by the platform defined constant
529 exception is taken, for example the current exception level, the CPU security
530 state (secure/non-secure), the exception type, and so on. This function is
533 * In BL1, whenever an exception is taken.
534 * In BL2, whenever an exception is taken.
566 doesn't do anything. Since this api is called during the power down sequence,
568 scratch registers. It should preserve the value in x18 register as it is used
579 warm boot. For each CPU, BL1 is responsible for the following tasks:
601 moment, its free memory will be available for BL2's use as-is. However, this
603 free memory (this is discussed in Section 3.2).
629 primary CPU is part of. It also enables the MMU.
639 This function executes with the MMU and data caches enabled. It is responsible
643 This function is also responsible for initializing the storage abstraction layer
644 which is used to load further bootloader images.
665 This information is used by BL1 to load the BL2 image in secure RAM. BL1 also
678 for it to use. This information is populated in a `meminfo`
684 to BL2. An illustration of how this is done in the ARM FVP port is given in the
693 This function is called after loading BL2 image and it can be used to overwrite
703 The BL2 stage is executed only by the primary CPU, which is determined in BL1
705 `BL2_BASE`. BL2 executes in Secure EL1 and is responsible for:
710 The platform also defines the address in memory where BL3-0 is loaded
712 to determine if there is enough memory to load the BL3-0 image.
713 Subsequent handling of the BL3-0 image is platform-specific and is
715 If `BL30_BASE` is not defined then this step is not performed.
719 by BL1. This structure allows BL2 to calculate how much secure RAM is
721 where BL3-1 is loaded through the constant `BL31_BASE`. BL2 uses this
722 information to determine if there is enough memory to load the BL3-1 image.
727 The platform also defines the address in memory where BL3-2 is loaded
729 to determine if there is enough memory to load the BL3-2 image.
730 If `BL32_BASE` is not defined then this and the next step is not performed.
739 address is determined using the `plat_get_ns_image_entrypoint()` function
755 This function executes with the MMU and data caches disabled. It is only called
756 by the primary CPU. The arguments to this function is the address of the
761 copied structure is made available to all BL2 code through the
770 This function executes with the MMU and data caches disabled. It is only called
773 The purpose of this function is to perform any architectural initialization
784 port does the necessary initialization in `bl2_plat_arch_setup()`. It is only
787 The purpose of this function is to perform any platform initialization
789 For the Base FVP the TZC-400 TrustZone controller is configured to only
794 This function is also responsible for initializing the storage abstraction layer
795 which is used to load further bootloader images.
805 initialization in `bl2_plat_arch_setup()`. It is only called by the primary CPU.
807 The purpose of this function is to return a pointer to a `meminfo` structure
817 This function is used to get the memory limits where BL2 can load the
818 BL3-0 image. The meminfo provided by this is used by load_image() to
828 This function is called after loading BL3-0 image and it is used to perform any
858 necessary content, or maintain the structures until BL3-3 is initialised.
866 BL2 platform code returns a pointer which is used to populate the entry point
870 On FVP this is allocated inside an bl2_to_bl31_params_mem structure which
871 is allocated at an address pointed by PARAMS_BASE.
879 This function is called after loading BL3-1 image and it can be used to
891 This function is called after loading BL3-2 image and it can be used to
903 This function is called after loading BL3-3 image and it can be used to
915 This function is used to get the memory limits where BL2 can load the
916 BL3-2 image. The meminfo provided by this is used by load_image() to
925 This function is used to get the memory limits where BL2 can load the
926 BL3-3 image. The meminfo provided by this is used by load_image() to
938 all these data to the main memory so that it is available when we jump to
946 As previously described, BL2 is responsible for arranging for control to be
950 BL2 is responsible for loading the normal world BL3-3 image (e.g. UEFI).
956 During cold boot, the BL3-1 stage is executed only by the primary CPU. This is
958 control to BL3-1 at `BL31_BASE`. During warm boot, BL3-1 is executed by all
959 CPUs. BL3-1 executes at EL3 and is responsible for:
963 that EL3 architectural and platform state is completely initialized. It
981 If BL3-1 is a reset vector, It also needs to handle the reset as specified in
993 This function executes with the MMU and data caches disabled. It is only called
1016 This function executes with the MMU and data caches disabled. It is only called
1019 The purpose of this function is to perform any architectural initialization
1030 port does the necessary initialization in `bl31_plat_arch_setup()`. It is only
1033 The purpose of this function is to complete platform initialization so that both
1053 This function is called by `bl31_main()` to retrieve information provided by
1064 The ARM Trusted Firmware's implementation of the PSCI API is based around the
1066 identified in a system by a CPU ID (the processor `MPIDR` is used in the PSCI
1068 CPU) is at level 0. If the CPUs in the system are described in a tree where the
1069 node above a CPU is a logical grouping of CPUs that share some state, then
1070 affinity level 1 is that group of CPUs (for example, a cluster), and affinity
1071 level 2 is a group of clusters (for example, the system). The implementation
1079 correctly. This information is populated in the `plat_pm_ops` structure. The
1082 CPU is specified by its `MPIDR` in a PSCI `CPU_ON` call. The `affinst_on()`
1083 handler (if present) is called for each affinity instance as the PSCI
1097 port does the necessary initializations in `bl31_plat_arch_setup()`. It is only
1100 This function is called by the PSCI initialization code to detect the system
1101 topology. Its purpose is to return the number of affinity instances implemented
1117 port does the necessary initializations in `bl31_plat_arch_setup()`. It is only
1120 This function is called by the PSCI initialization code. Its purpose is to
1121 return the state of an affinity instance. The affinity instance is determined by
1124 `PSCI_AFF_PRESENT` or `PSCI_AFF_ABSENT`. The latter state is used to cater for
1130 is missing but needs to be accounted for to reach this single CPU in the
1131 topology tree. Hence it is marked as `PSCI_AFF_ABSENT`.
1140 port does the necessary initializations in `bl31_plat_arch_setup()`. It is only
1143 This function is called by the PSCI implementation both during cold and warm
1145 operations should apply to. ARMv8-A has support for 4 affinity levels. It is
1159 port does the necessary initializations in `bl31_plat_arch_setup()`. It is only
1162 This function is called by PSCI initialization code. Its purpose is to export
1166 A description of each member of this structure is given below. Please refer to
1168 as an example. A platform port is expected to implement these handlers if the
1169 corresponding PSCI operation is to be supported and these handlers are expected
1170 to succeed if the return type is `void`.
1182 (ON or OFF). This is useful to determine whether any action must be taken. For
1192 calling CPU. It is called by the PSCI `CPU_OFF` API implementation.
1196 used to identify the affinity instance on which the call is made and its
1199 the calling CPU is the last powered on CPU in the cluster, after powering down
1206 calling CPU. It is called by the PSCI `CPU_SUSPEND` API and `SYSTEM_SUSPEND`
1211 identify the affinity instance on which the call is made and its current state.
1213 make to perform the requested action. For example, if the calling CPU is the
1218 is that in the former case, the affinity instance is expected to re-initialize
1220 case, the affinity instance is expected to save enough state so that it can
1226 This function is called by the PSCI implementation after the calling CPU is
1238 This function is called by the PSCI implementation after the calling CPU is
1251 This function is called by the PSCI implementation during the `CPU_SUSPEND`
1253 `power_state` is known to be invalid, the platform must return
1254 PSCI_E_INVALID_PARAMS as error, which is propagated back to the normal
1259 This function is called by the PSCI implementation during the `CPU_SUSPEND`,
1261 parameter passed by the normal world. If the `entry_point` is known to be
1262 invalid, the platform must return PSCI_E_INVALID_PARAMS as error, which is
1267 This function is called by the PSCI implementation during the `SYSTEM_SUSPEND`
1275 the state of each affinity instance in the topology. This information is
1284 state or EL3/S-EL1 in the secure state. The design of this framework is
1299 interrupt line. The specific line that is signaled depends on how the interrupt
1306 Guide]) indicating the target type of the interrupt, the second parameter is the
1307 security state of the originating execution context. The return result is the
1322 handler function. `INTR_TYPE_INVAL` is returned when there is no interrupt
1330 1. id < 1022 is reported as a S-EL1 interrupt
1331 2. id = 1022 is reported as a Non-secure interrupt.
1332 3. id = 1023 is reported as an invalid interrupt type.
1343 is set. INTR_ID_UNAVAILABLE is returned when there is no interrupt pending.
1346 (`GICC_HPPIR`) to determine the id of the pending interrupt. The id that is
1350 1. id < 1022. id is returned as is.
1352 (`GICC_AHPPIR`) is read to determine the id of the non-secure interrupt. This
1353 id is returned by the API.
1354 3. id = 1023. `INTR_ID_UNAVAILABLE` is returned.
1362 This API is used by the CPU to indicate to the platform IC that processing of
1364 interrupt which is being processed.
1369 `GICC_IAR`. This value is the id of the interrupt whose state has been changed.
1380 This API is used by the CPU to indicate to the platform IC that processing of
1399 `INTR_TYPE_INVAL` is returned if the id is invalid. If the id is valid, a valid
1400 interrupt type (one of `INTR_TYPE_EL3`, `INTR_TYPE_S_EL1` and `INTR_TYPE_NS`) is
1413 console is designated as the crash console by the platform which will be used to
1425 This API is used by the crash reporting mechanism to initialize the crash
1437 This API is used by the crash reporting mechanism to print a character on the
1459 By default, this flag is defined `yes` by the build system and `BL33`
1468 by the compiler are not used. The software is built with the `-nostdinc` flag
1472 implementation. If more functionality is required, the needed library functions
1483 extend the C library these files may need to be modified. It is recommended to
1505 layer is used to load data from non-volatile platform storage.
1510 storage access is only required by BL1 and BL2 phases. The `load_image()`
1513 It is mandatory to implement at least one storage driver. For the FVP the
1514 Firmware Image Package(FIP) driver is provided as the default means to load data
1516 The storage layer is described in the header file
1518 is in `drivers/io/io_storage.c` and the driver files are located in
1523 function that is called on platform initialization. The semi-hosting driver
1539 The layer is designed in such a way that is it possible to chain drivers with
1543 be deferred until the file-system device is initialised.