|
|
|
@ -8,7 +8,7 @@ Contents : |
|
|
|
3. [EL3 runtime services framework](#3--el3-runtime-services-framework) |
|
|
|
4. [Power State Coordination Interface](#4--power-state-coordination-interface) |
|
|
|
5. [Secure-EL1 Payloads and Dispatchers](#5--secure-el1-payloads-and-dispatchers) |
|
|
|
6. [Crash Reporting in BL3-1](#6--crash-reporting-in-bl3-1) |
|
|
|
6. [Crash Reporting in BL31](#6--crash-reporting-in-bl3-1) |
|
|
|
7. [Guidelines for Reset Handlers](#7--guidelines-for-reset-handlers) |
|
|
|
8. [CPU specific operations framework](#8--cpu-specific-operations-framework) |
|
|
|
9. [Memory layout of BL images](#9-memory-layout-of-bl-images) |
|
|
|
@ -56,9 +56,9 @@ into five steps (in order of execution): |
|
|
|
|
|
|
|
* Boot Loader stage 1 (BL1) _AP Trusted ROM_ |
|
|
|
* Boot Loader stage 2 (BL2) _Trusted Boot Firmware_ |
|
|
|
* Boot Loader stage 3-1 (BL3-1) _EL3 Runtime Firmware_ |
|
|
|
* Boot Loader stage 3-2 (BL3-2) _Secure-EL1 Payload_ (optional) |
|
|
|
* Boot Loader stage 3-3 (BL3-3) _Non-trusted Firmware_ |
|
|
|
* Boot Loader stage 3-1 (BL31) _EL3 Runtime Firmware_ |
|
|
|
* Boot Loader stage 3-2 (BL32) _Secure-EL1 Payload_ (optional) |
|
|
|
* Boot Loader stage 3-3 (BL33) _Non-trusted Firmware_ |
|
|
|
|
|
|
|
ARM development platforms (Fixed Virtual Platforms (FVPs) and Juno) implement a |
|
|
|
combination of the following types of memory regions. Each bootloader stage uses |
|
|
|
@ -76,10 +76,10 @@ one or more of these memory regions. |
|
|
|
The sections below provide the following details: |
|
|
|
|
|
|
|
* initialization and execution of the first three stages during cold boot |
|
|
|
* specification of the BL3-1 entrypoint requirements for use by alternative |
|
|
|
* specification of the BL31 entrypoint requirements for use by alternative |
|
|
|
Trusted Boot Firmware in place of the provided BL1 and BL2 |
|
|
|
* changes in BL3-1 behavior when using the `RESET_TO_BL31` option which |
|
|
|
allows BL3-1 to run without BL1 and BL2 |
|
|
|
* changes in BL31 behavior when using the `RESET_TO_BL31` option which |
|
|
|
allows BL31 to run without BL1 and BL2 |
|
|
|
|
|
|
|
|
|
|
|
### BL1 |
|
|
|
@ -150,7 +150,7 @@ BL1 performs minimal architectural initialization as follows. |
|
|
|
For the latter, BL1 installs a simple stub. The stub expects to receive |
|
|
|
only a single type of SMC (determined by its function ID in the general |
|
|
|
purpose register `X0`). This SMC is raised by BL2 to make BL1 pass control |
|
|
|
to BL3-1 (loaded by BL2) at EL3. Any other SMC leads to an assertion |
|
|
|
to BL31 (loaded by BL2) at EL3. Any other SMC leads to an assertion |
|
|
|
failure. |
|
|
|
|
|
|
|
* CPU initialization |
|
|
|
@ -240,104 +240,104 @@ bits. |
|
|
|
|
|
|
|
BL2 copies the information regarding the trusted SRAM populated by BL1 using a |
|
|
|
platform-specific mechanism. It calculates the limits of DRAM (main memory) |
|
|
|
to determine whether there is enough space to load the BL3-3 image. A platform |
|
|
|
defined base address is used to specify the load address for the BL3-1 image. |
|
|
|
It also defines the extents of memory available for use by the BL3-2 image. |
|
|
|
to determine whether there is enough space to load the BL33 image. A platform |
|
|
|
defined base address is used to specify the load address for the BL31 image. |
|
|
|
It also defines the extents of memory available for use by the BL32 image. |
|
|
|
BL2 also initializes a UART (PL011 console), which enables access to the |
|
|
|
`printf` family of functions in BL2. Platform security is initialized to allow |
|
|
|
access to controlled components. The storage abstraction layer is initialized |
|
|
|
which is used to load further bootloader images. |
|
|
|
|
|
|
|
#### BL3-0 (System Control Processor Firmware) image load |
|
|
|
#### SCP_BL2 (System Control Processor Firmware) image load |
|
|
|
|
|
|
|
Some systems have a separate System Control Processor (SCP) for power, clock, |
|
|
|
reset and system control. BL2 loads the optional BL3-0 image from platform |
|
|
|
reset and system control. BL2 loads the optional SCP_BL2 image from platform |
|
|
|
storage into a platform-specific region of secure memory. The subsequent |
|
|
|
handling of BL3-0 is platform specific. For example, on the Juno ARM development |
|
|
|
platform port the image is transferred into SCP's internal memory using the Boot |
|
|
|
Over MHU (BOM) protocol after being loaded in the trusted SRAM memory. The SCP |
|
|
|
executes BL3-0 and signals to the Application Processor (AP) for BL2 execution |
|
|
|
to continue. |
|
|
|
handling of SCP_BL2 is platform specific. For example, on the Juno ARM |
|
|
|
development platform port the image is transferred into SCP's internal memory |
|
|
|
using the Boot Over MHU (BOM) protocol after being loaded in the trusted SRAM |
|
|
|
memory. The SCP executes SCP_BL2 and signals to the Application Processor (AP) |
|
|
|
for BL2 execution to continue. |
|
|
|
|
|
|
|
#### BL3-1 (EL3 Runtime Firmware) image load |
|
|
|
#### BL31 (EL3 Runtime Firmware) image load |
|
|
|
|
|
|
|
BL2 loads the BL3-1 image from platform storage into a platform-specific address |
|
|
|
BL2 loads the BL31 image from platform storage into a platform-specific address |
|
|
|
in trusted SRAM. If there is not enough memory to load the image or image is |
|
|
|
missing it leads to an assertion failure. If the BL3-1 image loads successfully, |
|
|
|
BL2 updates the amount of trusted SRAM used and available for use by BL3-1. |
|
|
|
missing it leads to an assertion failure. If the BL31 image loads successfully, |
|
|
|
BL2 updates the amount of trusted SRAM used and available for use by BL31. |
|
|
|
This information is populated at a platform-specific memory address. |
|
|
|
|
|
|
|
#### BL3-2 (Secure-EL1 Payload) image load |
|
|
|
#### BL32 (Secure-EL1 Payload) image load |
|
|
|
|
|
|
|
BL2 loads the optional BL3-2 image from platform storage into a platform- |
|
|
|
BL2 loads the optional BL32 image from platform storage into a platform- |
|
|
|
specific region of secure memory. The image executes in the secure world. BL2 |
|
|
|
relies on BL3-1 to pass control to the BL3-2 image, if present. Hence, BL2 |
|
|
|
relies on BL31 to pass control to the BL32 image, if present. Hence, BL2 |
|
|
|
populates a platform-specific area of memory with the entrypoint/load-address |
|
|
|
of the BL3-2 image. The value of the Saved Processor Status Register (`SPSR`) |
|
|
|
for entry into BL3-2 is not determined by BL2, it is initialized by the |
|
|
|
Secure-EL1 Payload Dispatcher (see later) within BL3-1, which is responsible for |
|
|
|
managing interaction with BL3-2. This information is passed to BL3-1. |
|
|
|
of the BL32 image. The value of the Saved Processor Status Register (`SPSR`) |
|
|
|
for entry into BL32 is not determined by BL2, it is initialized by the |
|
|
|
Secure-EL1 Payload Dispatcher (see later) within BL31, which is responsible for |
|
|
|
managing interaction with BL32. This information is passed to BL31. |
|
|
|
|
|
|
|
#### BL3-3 (Non-trusted Firmware) image load |
|
|
|
#### BL33 (Non-trusted Firmware) image load |
|
|
|
|
|
|
|
BL2 loads the BL3-3 image (e.g. UEFI or other test or boot software) from |
|
|
|
BL2 loads the BL33 image (e.g. UEFI or other test or boot software) from |
|
|
|
platform storage into non-secure memory as defined by the platform. |
|
|
|
|
|
|
|
BL2 relies on BL3-1 to pass control to BL3-3 once secure state initialization is |
|
|
|
BL2 relies on BL31 to pass control to BL33 once secure state initialization is |
|
|
|
complete. Hence, BL2 populates a platform-specific area of memory with the |
|
|
|
entrypoint and Saved Program Status Register (`SPSR`) of the normal world |
|
|
|
software image. The entrypoint is the load address of the BL3-3 image. The |
|
|
|
software image. The entrypoint is the load address of the BL33 image. The |
|
|
|
`SPSR` is determined as specified in Section 5.13 of the [PSCI PDD] [PSCI]. This |
|
|
|
information is passed to BL3-1. |
|
|
|
information is passed to BL31. |
|
|
|
|
|
|
|
#### BL3-1 (EL3 Runtime Firmware) execution |
|
|
|
#### BL31 (EL3 Runtime Firmware) execution |
|
|
|
|
|
|
|
BL2 execution continues as follows: |
|
|
|
|
|
|
|
1. BL2 passes control back to BL1 by raising an SMC, providing BL1 with the |
|
|
|
BL3-1 entrypoint. The exception is handled by the SMC exception handler |
|
|
|
BL31 entrypoint. The exception is handled by the SMC exception handler |
|
|
|
installed by BL1. |
|
|
|
|
|
|
|
2. BL1 turns off the MMU and flushes the caches. It clears the |
|
|
|
`SCTLR_EL3.M/I/C` bits, flushes the data cache to the point of coherency |
|
|
|
and invalidates the TLBs. |
|
|
|
|
|
|
|
3. BL1 passes control to BL3-1 at the specified entrypoint at EL3. |
|
|
|
3. BL1 passes control to BL31 at the specified entrypoint at EL3. |
|
|
|
|
|
|
|
|
|
|
|
### BL3-1 |
|
|
|
### BL31 |
|
|
|
|
|
|
|
The image for this stage is loaded by BL2 and BL1 passes control to BL3-1 at |
|
|
|
EL3. BL3-1 executes solely in trusted SRAM. BL3-1 is linked against and |
|
|
|
The image for this stage is loaded by BL2 and BL1 passes control to BL31 at |
|
|
|
EL3. BL31 executes solely in trusted SRAM. BL31 is linked against and |
|
|
|
loaded at a platform-specific base address (more information can be found later |
|
|
|
in this document). The functionality implemented by BL3-1 is as follows. |
|
|
|
in this document). The functionality implemented by BL31 is as follows. |
|
|
|
|
|
|
|
#### Architectural initialization |
|
|
|
|
|
|
|
Currently, BL3-1 performs a similar architectural initialization to BL1 as |
|
|
|
Currently, BL31 performs a similar architectural initialization to BL1 as |
|
|
|
far as system register settings are concerned. Since BL1 code resides in ROM, |
|
|
|
architectural initialization in BL3-1 allows override of any previous |
|
|
|
initialization done by BL1. BL3-1 creates page tables to address the first |
|
|
|
architectural initialization in BL31 allows override of any previous |
|
|
|
initialization done by BL1. BL31 creates page tables to address the first |
|
|
|
4GB of physical address space and initializes the MMU accordingly. It initializes |
|
|
|
a buffer of frequently used pointers, called per-CPU pointer cache, in memory for |
|
|
|
faster access. Currently the per-CPU pointer cache contains only the pointer |
|
|
|
to crash stack. It then replaces the exception vectors populated by BL1 with its |
|
|
|
own. BL3-1 exception vectors implement more elaborate support for |
|
|
|
own. BL31 exception vectors implement more elaborate support for |
|
|
|
handling SMCs since this is the only mechanism to access the runtime services |
|
|
|
implemented by BL3-1 (PSCI for example). BL3-1 checks each SMC for validity as |
|
|
|
implemented by BL31 (PSCI for example). BL31 checks each SMC for validity as |
|
|
|
specified by the [SMC calling convention PDD][SMCCC] before passing control to |
|
|
|
the required SMC handler routine. BL3-1 programs the `CNTFRQ_EL0` register with |
|
|
|
the required SMC handler routine. BL31 programs the `CNTFRQ_EL0` register with |
|
|
|
the clock frequency of the system counter, which is provided by the platform. |
|
|
|
|
|
|
|
#### Platform initialization |
|
|
|
|
|
|
|
BL3-1 performs detailed platform initialization, which enables normal world |
|
|
|
BL31 performs detailed platform initialization, which enables normal world |
|
|
|
software to function correctly. It also retrieves entrypoint information for |
|
|
|
the BL3-3 image loaded by BL2 from the platform defined memory address populated |
|
|
|
the BL33 image loaded by BL2 from the platform defined memory address populated |
|
|
|
by BL2. It enables issuing of snoop and DVM (Distributed Virtual Memory) |
|
|
|
requests to the CCI slave interface corresponding to the cluster that includes |
|
|
|
the primary CPU. BL3-1 also initializes a UART (PL011 console), which enables |
|
|
|
access to the `printf` family of functions in BL3-1. It enables the system |
|
|
|
the primary CPU. BL31 also initializes a UART (PL011 console), which enables |
|
|
|
access to the `printf` family of functions in BL31. It enables the system |
|
|
|
level implementation of the generic timer through the memory mapped interface. |
|
|
|
|
|
|
|
* GICv2 initialization: |
|
|
|
@ -356,21 +356,21 @@ level implementation of the generic timer through the memory mapped interface. |
|
|
|
|
|
|
|
* GICv3 initialization: |
|
|
|
|
|
|
|
If a GICv3 implementation is available in the platform, BL3-1 initializes |
|
|
|
If a GICv3 implementation is available in the platform, BL31 initializes |
|
|
|
the GICv3 in GICv2 emulation mode with settings as described for GICv2 |
|
|
|
above. |
|
|
|
|
|
|
|
* Power management initialization: |
|
|
|
|
|
|
|
BL3-1 implements a state machine to track CPU and cluster state. The state |
|
|
|
BL31 implements a state machine to track CPU and cluster state. The state |
|
|
|
can be one of `OFF`, `ON_PENDING`, `SUSPEND` or `ON`. All secondary CPUs are |
|
|
|
initially in the `OFF` state. The cluster that the primary CPU belongs to is |
|
|
|
`ON`; any other cluster is `OFF`. BL3-1 initializes the data structures that |
|
|
|
implement the state machine, including the locks that protect them. BL3-1 |
|
|
|
`ON`; any other cluster is `OFF`. BL31 initializes the data structures that |
|
|
|
implement the state machine, including the locks that protect them. BL31 |
|
|
|
accesses the state of a CPU or cluster immediately after reset and before |
|
|
|
the data cache is enabled in the warm boot path. It is not currently |
|
|
|
possible to use 'exclusive' based spinlocks, therefore BL3-1 uses locks |
|
|
|
based on Lamport's Bakery algorithm instead. BL3-1 allocates these locks in |
|
|
|
possible to use 'exclusive' based spinlocks, therefore BL31 uses locks |
|
|
|
based on Lamport's Bakery algorithm instead. BL31 allocates these locks in |
|
|
|
device memory by default. |
|
|
|
|
|
|
|
* Runtime services initialization: |
|
|
|
@ -381,34 +381,34 @@ level implementation of the generic timer through the memory mapped interface. |
|
|
|
Details about the PSCI service are provided in the "Power State Coordination |
|
|
|
Interface" section below. |
|
|
|
|
|
|
|
* BL3-2 (Secure-EL1 Payload) image initialization |
|
|
|
* BL32 (Secure-EL1 Payload) image initialization |
|
|
|
|
|
|
|
If a BL3-2 image is present then there must be a matching Secure-EL1 Payload |
|
|
|
If a BL32 image is present then there must be a matching Secure-EL1 Payload |
|
|
|
Dispatcher (SPD) service (see later for details). During initialization |
|
|
|
that service must register a function to carry out initialization of BL3-2 |
|
|
|
once the runtime services are fully initialized. BL3-1 invokes such a |
|
|
|
registered function to initialize BL3-2 before running BL3-3. |
|
|
|
that service must register a function to carry out initialization of BL32 |
|
|
|
once the runtime services are fully initialized. BL31 invokes such a |
|
|
|
registered function to initialize BL32 before running BL33. |
|
|
|
|
|
|
|
Details on BL3-2 initialization and the SPD's role are described in the |
|
|
|
Details on BL32 initialization and the SPD's role are described in the |
|
|
|
"Secure-EL1 Payloads and Dispatchers" section below. |
|
|
|
|
|
|
|
* BL3-3 (Non-trusted Firmware) execution |
|
|
|
* BL33 (Non-trusted Firmware) execution |
|
|
|
|
|
|
|
BL3-1 initializes the EL2 or EL1 processor context for normal-world cold |
|
|
|
BL31 initializes the EL2 or EL1 processor context for normal-world cold |
|
|
|
boot, ensuring that no secure state information finds its way into the |
|
|
|
non-secure execution state. BL3-1 uses the entrypoint information provided |
|
|
|
by BL2 to jump to the Non-trusted firmware image (BL3-3) at the highest |
|
|
|
non-secure execution state. BL31 uses the entrypoint information provided |
|
|
|
by BL2 to jump to the Non-trusted firmware image (BL33) at the highest |
|
|
|
available Exception Level (EL2 if available, otherwise EL1). |
|
|
|
|
|
|
|
|
|
|
|
### Using alternative Trusted Boot Firmware in place of BL1 and BL2 |
|
|
|
|
|
|
|
Some platforms have existing implementations of Trusted Boot Firmware that |
|
|
|
would like to use ARM Trusted Firmware BL3-1 for the EL3 Runtime Firmware. To |
|
|
|
would like to use ARM Trusted Firmware BL31 for the EL3 Runtime Firmware. To |
|
|
|
enable this firmware architecture it is important to provide a fully documented |
|
|
|
and stable interface between the Trusted Boot Firmware and BL3-1. |
|
|
|
and stable interface between the Trusted Boot Firmware and BL31. |
|
|
|
|
|
|
|
Future changes to the BL3-1 interface will be done in a backwards compatible |
|
|
|
Future changes to the BL31 interface will be done in a backwards compatible |
|
|
|
way, and this enables these firmware components to be independently enhanced/ |
|
|
|
updated to develop and exploit new functionality. |
|
|
|
|
|
|
|
@ -425,58 +425,58 @@ EL3, little-endian data access, and all interrupt sources masked: |
|
|
|
SCTLR_EL3.EE = 0 |
|
|
|
|
|
|
|
X0 and X1 can be used to pass information from the Trusted Boot Firmware to the |
|
|
|
platform code in BL3-1: |
|
|
|
platform code in BL31: |
|
|
|
|
|
|
|
X0 : Reserved for common Trusted Firmware information |
|
|
|
X1 : Platform specific information |
|
|
|
|
|
|
|
BL3-1 zero-init sections (e.g. `.bss`) should not contain valid data on entry, |
|
|
|
BL31 zero-init sections (e.g. `.bss`) should not contain valid data on entry, |
|
|
|
these will be zero filled prior to invoking platform setup code. |
|
|
|
|
|
|
|
##### Use of the X0 and X1 parameters |
|
|
|
|
|
|
|
The parameters are platform specific and passed from `bl31_entrypoint()` to |
|
|
|
`bl31_early_platform_setup()`. The value of these parameters is never directly |
|
|
|
used by the common BL3-1 code. |
|
|
|
used by the common BL31 code. |
|
|
|
|
|
|
|
The convention is that `X0` conveys information regarding the BL3-1, BL3-2 and |
|
|
|
BL3-3 images from the Trusted Boot firmware and `X1` can be used for other |
|
|
|
The convention is that `X0` conveys information regarding the BL31, BL32 and |
|
|
|
BL33 images from the Trusted Boot firmware and `X1` can be used for other |
|
|
|
platform specific purpose. This convention allows platforms which use ARM |
|
|
|
Trusted Firmware's BL1 and BL2 images to transfer additional platform specific |
|
|
|
information from Secure Boot without conflicting with future evolution of the |
|
|
|
Trusted Firmware using `X0` to pass a `bl31_params` structure. |
|
|
|
|
|
|
|
BL3-1 common and SPD initialization code depends on image and entrypoint |
|
|
|
information about BL3-3 and BL3-2, which is provided via BL3-1 platform APIs. |
|
|
|
This information is required until the start of execution of BL3-3. This |
|
|
|
BL31 common and SPD initialization code depends on image and entrypoint |
|
|
|
information about BL33 and BL32, which is provided via BL31 platform APIs. |
|
|
|
This information is required until the start of execution of BL33. This |
|
|
|
information can be provided in a platform defined manner, e.g. compiled into |
|
|
|
the platform code in BL3-1, or provided in a platform defined memory location |
|
|
|
the platform code in BL31, or provided in a platform defined memory location |
|
|
|
by the Trusted Boot firmware, or passed from the Trusted Boot Firmware via the |
|
|
|
Cold boot Initialization parameters. This data may need to be cleaned out of |
|
|
|
the CPU caches if it is provided by an earlier boot stage and then accessed by |
|
|
|
BL3-1 platform code before the caches are enabled. |
|
|
|
BL31 platform code before the caches are enabled. |
|
|
|
|
|
|
|
ARM Trusted Firmware's BL2 implementation passes a `bl31_params` structure in |
|
|
|
`X0` and the ARM development platforms interpret this in the BL3-1 platform |
|
|
|
`X0` and the ARM development platforms interpret this in the BL31 platform |
|
|
|
code. |
|
|
|
|
|
|
|
##### MMU, Data caches & Coherency |
|
|
|
|
|
|
|
BL3-1 does not depend on the enabled state of the MMU, data caches or |
|
|
|
BL31 does not depend on the enabled state of the MMU, data caches or |
|
|
|
interconnect coherency on entry to `bl31_entrypoint()`. If these are disabled |
|
|
|
on entry, these should be enabled during `bl31_plat_arch_setup()`. |
|
|
|
|
|
|
|
##### Data structures used in the BL3-1 cold boot interface |
|
|
|
##### Data structures used in the BL31 cold boot interface |
|
|
|
|
|
|
|
These structures are designed to support compatibility and independent |
|
|
|
evolution of the structures and the firmware images. For example, a version of |
|
|
|
BL3-1 that can interpret the BL3-x image information from different versions of |
|
|
|
BL31 that can interpret the BL3x image information from different versions of |
|
|
|
BL2, a platform that uses an extended entry_point_info structure to convey |
|
|
|
additional register information to BL3-1, or a ELF image loader that can convey |
|
|
|
additional register information to BL31, or a ELF image loader that can convey |
|
|
|
more details about the firmware images. |
|
|
|
|
|
|
|
To support these scenarios the structures are versioned and sized, which enables |
|
|
|
BL3-1 to detect which information is present and respond appropriately. The |
|
|
|
BL31 to detect which information is present and respond appropriately. The |
|
|
|
`param_header` is defined to capture this information: |
|
|
|
|
|
|
|
typedef struct param_header { |
|
|
|
@ -491,7 +491,7 @@ The structures using this format are `entry_point_info`, `image_info` and |
|
|
|
the header fields appropriately, and the `SET_PARAM_HEAD()` a macro is defined |
|
|
|
to simplify this action. |
|
|
|
|
|
|
|
#### Required CPU state for BL3-1 Warm boot initialization |
|
|
|
#### Required CPU state for BL31 Warm boot initialization |
|
|
|
|
|
|
|
When requesting a CPU power-on, or suspending a running CPU, ARM Trusted |
|
|
|
Firmware provides the platform power management code with a Warm boot |
|
|
|
@ -510,49 +510,49 @@ platform power management code is then invoked as required to initialize all |
|
|
|
necessary system, cluster and CPU resources. |
|
|
|
|
|
|
|
|
|
|
|
### Using BL3-1 as the CPU reset vector |
|
|
|
### Using BL31 as the CPU reset vector |
|
|
|
|
|
|
|
On some platforms the runtime firmware (BL3-x images) for the application |
|
|
|
On some platforms the runtime firmware (BL3x images) for the application |
|
|
|
processors are loaded by trusted firmware running on a secure system processor |
|
|
|
on the SoC, rather than by BL1 and BL2 running on the primary application |
|
|
|
processor. For this type of SoC it is desirable for the application processor |
|
|
|
to always reset to BL3-1 which eliminates the need for BL1 and BL2. |
|
|
|
to always reset to BL31 which eliminates the need for BL1 and BL2. |
|
|
|
|
|
|
|
ARM Trusted Firmware provides a build-time option `RESET_TO_BL31` that includes |
|
|
|
some additional logic in the BL3-1 entrypoint to support this use case. |
|
|
|
some additional logic in the BL31 entrypoint to support this use case. |
|
|
|
|
|
|
|
In this configuration, the platform's Trusted Boot Firmware must ensure that |
|
|
|
BL3-1 is loaded to its runtime address, which must match the CPU's RVBAR reset |
|
|
|
BL31 is loaded to its runtime address, which must match the CPU's RVBAR reset |
|
|
|
vector address, before the application processor is powered on. Additionally, |
|
|
|
platform software is responsible for loading the other BL3-x images required and |
|
|
|
providing entry point information for them to BL3-1. Loading these images might |
|
|
|
be done by the Trusted Boot Firmware or by platform code in BL3-1. |
|
|
|
platform software is responsible for loading the other BL3x images required and |
|
|
|
providing entry point information for them to BL31. Loading these images might |
|
|
|
be done by the Trusted Boot Firmware or by platform code in BL31. |
|
|
|
|
|
|
|
The ARM FVP port supports the `RESET_TO_BL31` configuration, in which case the |
|
|
|
`bl31.bin` image must be loaded to its run address in Trusted SRAM and all CPU |
|
|
|
reset vectors be changed from the default `0x0` to this run address. See the |
|
|
|
[User Guide] for details of running the FVP models in this way. |
|
|
|
|
|
|
|
This configuration requires some additions and changes in the BL3-1 |
|
|
|
This configuration requires some additions and changes in the BL31 |
|
|
|
functionality: |
|
|
|
|
|
|
|
#### Determination of boot path |
|
|
|
|
|
|
|
In this configuration, BL3-1 uses the same reset framework and code as the one |
|
|
|
In this configuration, BL31 uses the same reset framework and code as the one |
|
|
|
described for BL1 above. On a warm boot a CPU is directed to the PSCI |
|
|
|
implementation via a platform defined mechanism. On a cold boot, the platform |
|
|
|
must place any secondary CPUs into a safe state while the primary CPU executes |
|
|
|
a modified BL3-1 initialization, as described below. |
|
|
|
a modified BL31 initialization, as described below. |
|
|
|
|
|
|
|
#### Platform initialization |
|
|
|
|
|
|
|
In this configuration, when the CPU resets to BL3-1 there are no parameters |
|
|
|
In this configuration, when the CPU resets to BL31 there are no parameters |
|
|
|
that can be passed in registers by previous boot stages. Instead, the platform |
|
|
|
code in BL3-1 needs to know, or be able to determine, the location of the BL3-2 |
|
|
|
(if required) and BL3-3 images and provide this information in response to the |
|
|
|
code in BL31 needs to know, or be able to determine, the location of the BL32 |
|
|
|
(if required) and BL33 images and provide this information in response to the |
|
|
|
`bl31_plat_get_next_image_ep_info()` function. |
|
|
|
|
|
|
|
As the first image to execute in this configuration BL3-1 must also ensure that |
|
|
|
As the first image to execute in this configuration BL31 must also ensure that |
|
|
|
any security initialisation, for example programming a TrustZone address space |
|
|
|
controller, is carried out during early platform initialisation. |
|
|
|
|
|
|
|
@ -571,7 +571,7 @@ The EL3 runtime services framework enables the development of services by |
|
|
|
different providers that can be easily integrated into final product firmware. |
|
|
|
The following sections describe the framework which facilitates the |
|
|
|
registration, initialization and use of runtime services in EL3 Runtime |
|
|
|
Firmware (BL3-1). |
|
|
|
Firmware (BL31). |
|
|
|
|
|
|
|
The design of the runtime services depends heavily on the concepts and |
|
|
|
definitions described in the [SMCCC], in particular SMC Function IDs, Owning |
|
|
|
@ -628,7 +628,7 @@ the name of the service, the range of OENs covered, the type of service and |
|
|
|
initialization and call handler functions. This macro instantiates a `const |
|
|
|
struct rt_svc_desc` for the service with these details (see `runtime_svc.h`). |
|
|
|
This structure is allocated in a special ELF section `rt_svc_descs`, enabling |
|
|
|
the framework to find all service descriptors included into BL3-1. |
|
|
|
the framework to find all service descriptors included into BL31. |
|
|
|
|
|
|
|
The specific service for a SMC Function is selected based on the OEN and call |
|
|
|
type of the Function ID, and the framework uses that information in the service |
|
|
|
@ -650,14 +650,14 @@ call handling functions are provided in the following sections. |
|
|
|
### Initialization |
|
|
|
|
|
|
|
`runtime_svc_init()` in `runtime_svc.c` initializes the runtime services |
|
|
|
framework running on the primary CPU during cold boot as part of the BL3-1 |
|
|
|
framework running on the primary CPU during cold boot as part of the BL31 |
|
|
|
initialization. This happens prior to initializing a Trusted OS and running |
|
|
|
Normal world boot firmware that might in turn use these services. |
|
|
|
Initialization involves validating each of the declared runtime service |
|
|
|
descriptors, calling the service initialization function and populating the |
|
|
|
index used for runtime lookup of the service. |
|
|
|
|
|
|
|
The BL3-1 linker script collects all of the declared service descriptors into a |
|
|
|
The BL31 linker script collects all of the declared service descriptors into a |
|
|
|
single array and defines symbols that allow the framework to locate and traverse |
|
|
|
the array, and determine its size. |
|
|
|
|
|
|
|
@ -771,22 +771,22 @@ hooks to be registered with the generic PSCI code to be supported. |
|
|
|
--------------------------------------- |
|
|
|
|
|
|
|
On a production system that includes a Trusted OS running in Secure-EL1/EL0, |
|
|
|
the Trusted OS is coupled with a companion runtime service in the BL3-1 |
|
|
|
the Trusted OS is coupled with a companion runtime service in the BL31 |
|
|
|
firmware. This service is responsible for the initialisation of the Trusted |
|
|
|
OS and all communications with it. The Trusted OS is the BL3-2 stage of the |
|
|
|
OS and all communications with it. The Trusted OS is the BL32 stage of the |
|
|
|
boot flow in ARM Trusted Firmware. The firmware will attempt to locate, load |
|
|
|
and execute a BL3-2 image. |
|
|
|
and execute a BL32 image. |
|
|
|
|
|
|
|
ARM Trusted Firmware uses a more general term for the BL3-2 software that runs |
|
|
|
ARM Trusted Firmware uses a more general term for the BL32 software that runs |
|
|
|
at Secure-EL1 - the _Secure-EL1 Payload_ - as it is not always a Trusted OS. |
|
|
|
|
|
|
|
The ARM Trusted Firmware provides a Test Secure-EL1 Payload (TSP) and a Test |
|
|
|
Secure-EL1 Payload Dispatcher (TSPD) service as an example of how a Trusted OS |
|
|
|
is supported on a production system using the Runtime Services Framework. On |
|
|
|
such a system, the Test BL3-2 image and service are replaced by the Trusted OS |
|
|
|
such a system, the Test BL32 image and service are replaced by the Trusted OS |
|
|
|
and its dispatcher service. The ARM Trusted Firmware build system expects that |
|
|
|
the dispatcher will define the build flag `NEED_BL32` to enable it to include |
|
|
|
the BL3-2 in the build either as a binary or to compile from source depending |
|
|
|
the BL32 in the build either as a binary or to compile from source depending |
|
|
|
on whether the `BL32` build option is specified or not. |
|
|
|
|
|
|
|
The TSP runs in Secure-EL1. It is designed to demonstrate synchronous |
|
|
|
@ -806,69 +806,69 @@ The TSPD service is responsible for. |
|
|
|
* Routing requests and responses between the secure and the non-secure |
|
|
|
states during the two types of communications just described |
|
|
|
|
|
|
|
### Initializing a BL3-2 Image |
|
|
|
### Initializing a BL32 Image |
|
|
|
|
|
|
|
The Secure-EL1 Payload Dispatcher (SPD) service is responsible for initializing |
|
|
|
the BL3-2 image. It needs access to the information passed by BL2 to BL3-1 to do |
|
|
|
the BL32 image. It needs access to the information passed by BL2 to BL31 to do |
|
|
|
so. This is provided by: |
|
|
|
|
|
|
|
entry_point_info_t *bl31_plat_get_next_image_ep_info(uint32_t); |
|
|
|
|
|
|
|
which returns a reference to the `entry_point_info` structure corresponding to |
|
|
|
the image which will be run in the specified security state. The SPD uses this |
|
|
|
API to get entry point information for the SECURE image, BL3-2. |
|
|
|
API to get entry point information for the SECURE image, BL32. |
|
|
|
|
|
|
|
In the absence of a BL3-2 image, BL3-1 passes control to the normal world |
|
|
|
bootloader image (BL3-3). When the BL3-2 image is present, it is typical |
|
|
|
that the SPD wants control to be passed to BL3-2 first and then later to BL3-3. |
|
|
|
In the absence of a BL32 image, BL31 passes control to the normal world |
|
|
|
bootloader image (BL33). When the BL32 image is present, it is typical |
|
|
|
that the SPD wants control to be passed to BL32 first and then later to BL33. |
|
|
|
|
|
|
|
To do this the SPD has to register a BL3-2 initialization function during |
|
|
|
initialization of the SPD service. The BL3-2 initialization function has this |
|
|
|
To do this the SPD has to register a BL32 initialization function during |
|
|
|
initialization of the SPD service. The BL32 initialization function has this |
|
|
|
prototype: |
|
|
|
|
|
|
|
int32_t init(); |
|
|
|
|
|
|
|
and is registered using the `bl31_register_bl32_init()` function. |
|
|
|
|
|
|
|
Trusted Firmware supports two approaches for the SPD to pass control to BL3-2 |
|
|
|
before returning through EL3 and running the non-trusted firmware (BL3-3): |
|
|
|
Trusted Firmware supports two approaches for the SPD to pass control to BL32 |
|
|
|
before returning through EL3 and running the non-trusted firmware (BL33): |
|
|
|
|
|
|
|
1. In the BL3-2 setup function, use `bl31_set_next_image_type()` to |
|
|
|
request that the exit from `bl31_main()` is to the BL3-2 entrypoint in |
|
|
|
Secure-EL1. BL3-1 will exit to BL3-2 using the asynchronous method by |
|
|
|
1. In the BL32 setup function, use `bl31_set_next_image_type()` to |
|
|
|
request that the exit from `bl31_main()` is to the BL32 entrypoint in |
|
|
|
Secure-EL1. BL31 will exit to BL32 using the asynchronous method by |
|
|
|
calling bl31_prepare_next_image_entry() and el3_exit(). |
|
|
|
|
|
|
|
When the BL3-2 has completed initialization at Secure-EL1, it returns to |
|
|
|
BL3-1 by issuing an SMC, using a Function ID allocated to the SPD. On |
|
|
|
When the BL32 has completed initialization at Secure-EL1, it returns to |
|
|
|
BL31 by issuing an SMC, using a Function ID allocated to the SPD. On |
|
|
|
receipt of this SMC, the SPD service handler should switch the CPU context |
|
|
|
from trusted to normal world and use the `bl31_set_next_image_type()` and |
|
|
|
`bl31_prepare_next_image_entry()` functions to set up the initial return to |
|
|
|
the normal world firmware BL3-3. On return from the handler the framework |
|
|
|
will exit to EL2 and run BL3-3. |
|
|
|
the normal world firmware BL33. On return from the handler the framework |
|
|
|
will exit to EL2 and run BL33. |
|
|
|
|
|
|
|
2. The BL3-2 setup function registers a initialization function using |
|
|
|
2. The BL32 setup function registers a initialization function using |
|
|
|
`bl31_register_bl32_init()` which provides a SPD-defined mechanism to |
|
|
|
invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL3-2 |
|
|
|
invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32 |
|
|
|
entrypoint. |
|
|
|
NOTE: The Test SPD service included with the Trusted Firmware provides one |
|
|
|
implementation of such a mechanism. |
|
|
|
|
|
|
|
On completion BL3-2 returns control to BL3-1 via a SMC, and on receipt the |
|
|
|
On completion BL32 returns control to BL31 via a SMC, and on receipt the |
|
|
|
SPD service handler invokes the synchronous call return mechanism to return |
|
|
|
to the BL3-2 initialization function. On return from this function, |
|
|
|
`bl31_main()` will set up the return to the normal world firmware BL3-3 and |
|
|
|
to the BL32 initialization function. On return from this function, |
|
|
|
`bl31_main()` will set up the return to the normal world firmware BL33 and |
|
|
|
continue the boot process in the normal world. |
|
|
|
|
|
|
|
|
|
|
|
6. Crash Reporting in BL3-1 |
|
|
|
6. Crash Reporting in BL31 |
|
|
|
---------------------------- |
|
|
|
|
|
|
|
BL3-1 implements a scheme for reporting the processor state when an unhandled |
|
|
|
BL31 implements a scheme for reporting the processor state when an unhandled |
|
|
|
exception is encountered. The reporting mechanism attempts to preserve all the |
|
|
|
register contents and report it via a dedicated UART (PL011 console). BL3-1 |
|
|
|
register contents and report it via a dedicated UART (PL011 console). BL31 |
|
|
|
reports the general purpose, EL3, Secure EL1 and some EL2 state registers. |
|
|
|
|
|
|
|
A dedicated per-CPU crash stack is maintained by BL3-1 and this is retrieved via |
|
|
|
A dedicated per-CPU crash stack is maintained by BL31 and this is retrieved via |
|
|
|
the per-CPU pointer cache. The implementation attempts to minimise the memory |
|
|
|
required for this feature. The file `crash_reporting.S` contains the |
|
|
|
implementation for crash reporting. |
|
|
|
@ -960,7 +960,7 @@ The sample crash output is shown below. |
|
|
|
Trusted Firmware implements a framework that allows CPU and platform ports to |
|
|
|
perform actions very early after a CPU is released from reset in both the cold |
|
|
|
and warm boot paths. This is done by calling the `reset_handler()` function in |
|
|
|
both the BL1 and BL3-1 images. It in turn calls the platform and CPU specific |
|
|
|
both the BL1 and BL31 images. It in turn calls the platform and CPU specific |
|
|
|
reset handling functions. |
|
|
|
|
|
|
|
Details for implementing a CPU specific reset handler can be found in |
|
|
|
@ -1045,7 +1045,7 @@ regarding placement of code in a reset handler. |
|
|
|
|
|
|
|
### CPU specific power down sequence |
|
|
|
|
|
|
|
During the BL3-1 initialization sequence, the pointer to the matching `cpu_ops` |
|
|
|
During the BL31 initialization sequence, the pointer to the matching `cpu_ops` |
|
|
|
entry is stored in per-CPU data by `init_cpu_ops()` so that it can be quickly |
|
|
|
retrieved during power down sequences. |
|
|
|
|
|
|
|
@ -1065,7 +1065,7 @@ turning off CCI coherency during a cluster power down. |
|
|
|
|
|
|
|
### CPU specific register reporting during crash |
|
|
|
|
|
|
|
If the crash reporting is enabled in BL3-1, when a crash occurs, the crash |
|
|
|
If the crash reporting is enabled in BL31, when a crash occurs, the crash |
|
|
|
reporting framework calls `do_cpu_reg_dump` which retrieves the matching |
|
|
|
`cpu_ops` using `get_cpu_ops_ptr()` function. The `cpu_reg_dump()` in |
|
|
|
`cpu_ops` is invoked, which then returns the CPU specific register values to |
|
|
|
@ -1182,9 +1182,9 @@ for this purpose: |
|
|
|
* `__BL1_RAM_START__` This is the start address of BL1 RW data. |
|
|
|
* `__BL1_RAM_END__` This is the end address of BL1 RW data. |
|
|
|
|
|
|
|
#### BL2's, BL3-1's and TSP's linker symbols |
|
|
|
#### BL2's, BL31's and TSP's linker symbols |
|
|
|
|
|
|
|
BL2, BL3-1 and TSP need to know the extents of their read-only section to set |
|
|
|
BL2, BL31 and TSP need to know the extents of their read-only section to set |
|
|
|
the right memory attributes for this memory region in their MMU setup code. The |
|
|
|
following linker symbols are defined for this purpose: |
|
|
|
|
|
|
|
@ -1221,7 +1221,7 @@ happens, the linker will issue a message similar to the following: |
|
|
|
aarch64-none-elf-ld: BLx has exceeded its limit. |
|
|
|
|
|
|
|
Additionally, if the platform memory layout implies some image overlaying like |
|
|
|
on FVP, BL3-1 and TSP need to know the limit address that their PROGBITS |
|
|
|
on FVP, BL31 and TSP need to know the limit address that their PROGBITS |
|
|
|
sections must not overstep. The platform code must provide those. |
|
|
|
|
|
|
|
|
|
|
|
@ -1242,45 +1242,45 @@ The following list describes the memory layout on the ARM development platforms: |
|
|
|
Juno, BL1 resides in flash memory at address `0x0BEC0000`. BL1 read-write |
|
|
|
data are relocated to the top of Trusted SRAM at runtime. |
|
|
|
|
|
|
|
* BL3-1 is loaded at the top of the Trusted SRAM, such that its NOBITS |
|
|
|
* BL31 is loaded at the top of the Trusted SRAM, such that its NOBITS |
|
|
|
sections will overwrite BL1 R/W data. This implies that BL1 global variables |
|
|
|
remain valid only until execution reaches the BL3-1 entry point during |
|
|
|
remain valid only until execution reaches the BL31 entry point during |
|
|
|
a cold boot. |
|
|
|
|
|
|
|
* BL2 is loaded below BL3-1. |
|
|
|
* BL2 is loaded below BL31. |
|
|
|
|
|
|
|
* On Juno, BL3-0 is loaded temporarily into the BL3-1 memory region and |
|
|
|
transfered to the SCP before being overwritten by BL3-1. |
|
|
|
* On Juno, SCP_BL2 is loaded temporarily into the BL31 memory region and |
|
|
|
transfered to the SCP before being overwritten by BL31. |
|
|
|
|
|
|
|
* BL3-2 can be loaded in one of the following locations: |
|
|
|
* BL32 can be loaded in one of the following locations: |
|
|
|
|
|
|
|
* Trusted SRAM |
|
|
|
* Trusted DRAM (FVP only) |
|
|
|
* Secure region of DRAM (top 16MB of DRAM configured by the TrustZone |
|
|
|
controller) |
|
|
|
|
|
|
|
When BL3-2 is loaded into Trusted SRAM, its NOBITS sections are allowed to |
|
|
|
overlay BL2. This memory layout is designed to give the BL3-2 image as much |
|
|
|
When BL32 is loaded into Trusted SRAM, its NOBITS sections are allowed to |
|
|
|
overlay BL2. This memory layout is designed to give the BL32 image as much |
|
|
|
memory as possible when it is loaded into Trusted SRAM. |
|
|
|
|
|
|
|
The location of the BL3-2 image will result in different memory maps. This is |
|
|
|
The location of the BL32 image will result in different memory maps. This is |
|
|
|
illustrated for both FVP and Juno in the following diagrams, using the TSP as |
|
|
|
an example. |
|
|
|
|
|
|
|
Note: Loading the BL3-2 image in TZC secured DRAM doesn't change the memory |
|
|
|
Note: Loading the BL32 image in TZC secured DRAM doesn't change the memory |
|
|
|
layout of the other images in Trusted SRAM. |
|
|
|
|
|
|
|
**FVP with TSP in Trusted SRAM (default option):** |
|
|
|
|
|
|
|
Trusted SRAM |
|
|
|
0x04040000 +----------+ loaded by BL2 ------------------ |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| | <<<<<<<<<<<<< | BL3-1 PROGBITS | |
|
|
|
| | <<<<<<<<<<<<< | BL31 PROGBITS | |
|
|
|
|----------| ------------------ |
|
|
|
| BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS | |
|
|
|
| BL2 | <<<<<<<<<<<<< | BL32 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| | <<<<<<<<<<<<< | BL3-2 PROGBITS | |
|
|
|
| | <<<<<<<<<<<<< | BL32 PROGBITS | |
|
|
|
0x04001000 +----------+ ------------------ |
|
|
|
| Shared | |
|
|
|
0x04000000 +----------+ |
|
|
|
@ -1295,14 +1295,14 @@ layout of the other images in Trusted SRAM. |
|
|
|
|
|
|
|
Trusted DRAM |
|
|
|
0x08000000 +----------+ |
|
|
|
| BL3-2 | |
|
|
|
| BL32 | |
|
|
|
0x06000000 +----------+ |
|
|
|
|
|
|
|
Trusted SRAM |
|
|
|
0x04040000 +----------+ loaded by BL2 ------------------ |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| | <<<<<<<<<<<<< | BL3-1 PROGBITS | |
|
|
|
| | <<<<<<<<<<<<< | BL31 PROGBITS | |
|
|
|
|----------| ------------------ |
|
|
|
| BL2 | |
|
|
|
|----------| |
|
|
|
@ -1320,7 +1320,7 @@ layout of the other images in Trusted SRAM. |
|
|
|
|
|
|
|
DRAM |
|
|
|
0xffffffff +----------+ |
|
|
|
| BL3-2 | (secure) |
|
|
|
| BL32 | (secure) |
|
|
|
0xff000000 +----------+ |
|
|
|
| | |
|
|
|
: : (non-secure) |
|
|
|
@ -1329,9 +1329,9 @@ layout of the other images in Trusted SRAM. |
|
|
|
|
|
|
|
Trusted SRAM |
|
|
|
0x04040000 +----------+ loaded by BL2 ------------------ |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| | <<<<<<<<<<<<< | BL3-1 PROGBITS | |
|
|
|
| | <<<<<<<<<<<<< | BL31 PROGBITS | |
|
|
|
|----------| ------------------ |
|
|
|
| BL2 | |
|
|
|
|----------| |
|
|
|
@ -1346,7 +1346,7 @@ layout of the other images in Trusted SRAM. |
|
|
|
0x00000000 +----------+ |
|
|
|
|
|
|
|
|
|
|
|
**Juno with BL3-2 in Trusted SRAM (default option):** |
|
|
|
**Juno with BL32 in Trusted SRAM (default option):** |
|
|
|
|
|
|
|
Flash0 |
|
|
|
0x0C000000 +----------+ |
|
|
|
@ -1355,27 +1355,27 @@ layout of the other images in Trusted SRAM. |
|
|
|
| BL1 (ro) | |
|
|
|
0x0BEC0000 |----------| |
|
|
|
: : |
|
|
|
0x08000000 +----------+ BL3-1 is loaded |
|
|
|
after BL3-0 has |
|
|
|
0x08000000 +----------+ BL31 is loaded |
|
|
|
after SCP_BL2 has |
|
|
|
Trusted SRAM been sent to SCP |
|
|
|
0x04040000 +----------+ loaded by BL2 ------------------ |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| BL3-0 | <<<<<<<<<<<<< | BL3-1 PROGBITS | |
|
|
|
| SCP_BL2 | <<<<<<<<<<<<< | BL31 PROGBITS | |
|
|
|
|----------| ------------------ |
|
|
|
| BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS | |
|
|
|
| BL2 | <<<<<<<<<<<<< | BL32 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| | <<<<<<<<<<<<< | BL3-2 PROGBITS | |
|
|
|
| | <<<<<<<<<<<<< | BL32 PROGBITS | |
|
|
|
0x04001000 +----------+ ------------------ |
|
|
|
| MHU | |
|
|
|
0x04000000 +----------+ |
|
|
|
|
|
|
|
|
|
|
|
**Juno with BL3-2 in TZC-secured DRAM:** |
|
|
|
**Juno with BL32 in TZC-secured DRAM:** |
|
|
|
|
|
|
|
DRAM |
|
|
|
0xFFE00000 +----------+ |
|
|
|
| BL3-2 | (secure) |
|
|
|
| BL32 | (secure) |
|
|
|
0xFF000000 |----------| |
|
|
|
| | |
|
|
|
: : (non-secure) |
|
|
|
@ -1389,13 +1389,13 @@ layout of the other images in Trusted SRAM. |
|
|
|
| BL1 (ro) | |
|
|
|
0x0BEC0000 |----------| |
|
|
|
: : |
|
|
|
0x08000000 +----------+ BL3-1 is loaded |
|
|
|
after BL3-0 has |
|
|
|
0x08000000 +----------+ BL31 is loaded |
|
|
|
after SCP_BL2 has |
|
|
|
Trusted SRAM been sent to SCP |
|
|
|
0x04040000 +----------+ loaded by BL2 ------------------ |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |
|
|
|
| BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | |
|
|
|
|----------| <<<<<<<<<<<<< |----------------| |
|
|
|
| BL3-0 | <<<<<<<<<<<<< | BL3-1 PROGBITS | |
|
|
|
| SCP_BL2 | <<<<<<<<<<<<< | BL31 PROGBITS | |
|
|
|
|----------| ------------------ |
|
|
|
| BL2 | |
|
|
|
|----------| |
|
|
|
@ -1722,7 +1722,7 @@ following categories (present as directories in the source code): |
|
|
|
Each boot loader stage uses code from one or more of the above mentioned |
|
|
|
categories. Based upon the above, the code layout looks like this: |
|
|
|
|
|
|
|
Directory Used by BL1? Used by BL2? Used by BL3-1? |
|
|
|
Directory Used by BL1? Used by BL2? Used by BL31? |
|
|
|
bl1 Yes No No |
|
|
|
bl2 No Yes No |
|
|
|
bl31 No No Yes |
|
|
|
|
danh-arm
9 years ago