Replace all SCP FW (BL0, BL3-0) references
This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):
BL0 --> SCP_BL1
BL30, BL3-0 --> SCP_BL2
bl30 --> scp_bl2
This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.
IMPORTANT: build option to specify the SCP FW image has changed:
BL30 --> SCP_BL2
IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:
BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
BL30_BASE --> SCP_BL2_BASE
bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
diff --git a/docs/auth-framework.md b/docs/auth-framework.md
index b910eae..f6455b9 100644
--- a/docs/auth-framework.md
+++ b/docs/auth-framework.md
@@ -211,8 +211,9 @@
3. Tracking which images have been verified. In case an image is a part of
multiple CoTs then it should be verified only once e.g. the Trusted World
Key Certificate in the TBBR-Client spec. contains information to verify
- BL3-0, BL3-1, BL3-2 each of which have a separate CoT. (This responsibility
- has not been described in this document but should be trivial to implement).
+ SCP_BL2, BL3-1, BL3-2 each of which have a separate CoT. (This
+ responsibility has not been described in this document but should be
+ trivial to implement).
4. Reusing memory meant for a data image to verify authentication images e.g.
in the CoT described in Diagram 2, each certificate can be loaded and
@@ -632,7 +633,7 @@
and thus all CoTs must present:
* `BL2`
-* `BL3-0` (platform specific)
+* `SCP_BL2` (platform specific)
* `BL3-1`
* `BL3-2` (optional)
* `BL3-3`
diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index 41fb7c0..51084f4 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -248,16 +248,16 @@
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
@@ -1249,7 +1249,7 @@
* BL2 is loaded below BL3-1.
-* On Juno, BL3-0 is loaded temporarily into the BL3-1 memory region and
+* On Juno, SCP_BL2 is loaded temporarily into the BL3-1 memory region and
transfered to the SCP before being overwritten by BL3-1.
* BL3-2 can be loaded in one of the following locations:
@@ -1356,12 +1356,12 @@
0x0BEC0000 |----------|
: :
0x08000000 +----------+ BL3-1 is loaded
- after BL3-0 has
+ after SCP_BL2 has
Trusted SRAM been sent to SCP
0x04040000 +----------+ loaded by BL2 ------------------
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS |
|----------| <<<<<<<<<<<<< |----------------|
- | BL3-0 | <<<<<<<<<<<<< | BL3-1 PROGBITS |
+ | SCP_BL2 | <<<<<<<<<<<<< | BL3-1 PROGBITS |
|----------| ------------------
| BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS |
|----------| <<<<<<<<<<<<< |----------------|
@@ -1390,12 +1390,12 @@
0x0BEC0000 |----------|
: :
0x08000000 +----------+ BL3-1 is loaded
- after BL3-0 has
+ after SCP_BL2 has
Trusted SRAM been sent to SCP
0x04040000 +----------+ loaded by BL2 ------------------
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS |
|----------| <<<<<<<<<<<<< |----------------|
- | BL3-0 | <<<<<<<<<<<<< | BL3-1 PROGBITS |
+ | SCP_BL2 | <<<<<<<<<<<<< | BL3-1 PROGBITS |
|----------| ------------------
| BL2 |
|----------|
diff --git a/docs/porting-guide.md b/docs/porting-guide.md
index b77377f..5e80a7f 100644
--- a/docs/porting-guide.md
+++ b/docs/porting-guide.md
@@ -277,23 +277,23 @@
BL3-3 content certificate identifier, used by BL2 to load the BL3-3 content
certificate.
-If a BL3-0 image is supported by the platform, the following constants must
+If a SCP_BL2 image is supported by the platform, the following constants must
also be defined:
-* **#define : BL30_IMAGE_ID**
+* **#define : SCP_BL2_IMAGE_ID**
- BL3-0 image identifier, used by BL2 to load BL3-0 into secure memory from
- platform storage before being transfered to the SCP.
+ SCP_BL2 image identifier, used by BL2 to load SCP_BL2 into secure memory
+ from platform storage before being transfered to the SCP.
* **#define : SCP_FW_KEY_CERT_ID**
- BL3-0 key certificate identifier, used by BL2 to load the BL3-0 key
+ SCP_BL2 key certificate identifier, used by BL2 to load the SCP_BL2 key
certificate (mandatory when Trusted Board Boot is enabled).
* **#define : SCP_FW_CONTENT_CERT_ID**
- BL3-0 content certificate identifier, used by BL2 to load the BL3-0 content
- certificate (mandatory when Trusted Board Boot is enabled).
+ SCP_BL2 content certificate identifier, used by BL2 to load the SCP_BL2
+ content certificate (mandatory when Trusted Board Boot is enabled).
If a BL3-2 image is supported by the platform, the following constants must
also be defined:
@@ -838,15 +838,15 @@
using the `platform_is_primary_cpu()` function. BL1 passed control to BL2 at
`BL2_BASE`. BL2 executes in Secure EL1 and is responsible for:
-1. (Optional) Loading the BL3-0 binary image (if present) from platform
- provided non-volatile storage. To load the BL3-0 image, BL2 makes use of
- the `meminfo` returned by the `bl2_plat_get_bl30_meminfo()` function.
- The platform also defines the address in memory where BL3-0 is loaded
- through the optional constant `BL30_BASE`. BL2 uses this information
- to determine if there is enough memory to load the BL3-0 image.
- Subsequent handling of the BL3-0 image is platform-specific and is
- implemented in the `bl2_plat_handle_bl30()` function.
- If `BL30_BASE` is not defined then this step is not performed.
+1. (Optional) Loading the SCP_BL2 binary image (if present) from platform
+ provided non-volatile storage. To load the SCP_BL2 image, BL2 makes use of
+ the `meminfo` returned by the `bl2_plat_get_scp_bl2_meminfo()` function.
+ The platform also defines the address in memory where SCP_BL2 is loaded
+ through the optional constant `SCP_BL2_BASE`. BL2 uses this information
+ to determine if there is enough memory to load the SCP_BL2 image.
+ Subsequent handling of the SCP_BL2 image is platform-specific and is
+ implemented in the `bl2_plat_handle_scp_bl2()` function.
+ If `SCP_BL2_BASE` is not defined then this step is not performed.
2. Loading the BL3-1 binary image into secure RAM from non-volatile storage. To
load the BL3-1 image, BL2 makes use of the `meminfo` structure passed to it
@@ -897,8 +897,8 @@
In ARM standard platforms, this function also initializes the storage
abstraction layer used to load further bootloader images. It is necessary to do
-this early on platforms with a BL3-0 image, since the later `bl2_platform_setup`
-must be done after BL3-0 is loaded.
+this early on platforms with a SCP_BL2 image, since the later
+`bl2_platform_setup` must be done after SCP_BL2 is loaded.
### Function : bl2_plat_arch_setup() [mandatory]
@@ -945,24 +945,24 @@
`bl2_early_platform_setup()` above.
-### Function : bl2_plat_get_bl30_meminfo() [mandatory]
+### Function : bl2_plat_get_scp_bl2_meminfo() [mandatory]
Argument : meminfo *
Return : void
This function is used to get the memory limits where BL2 can load the
-BL3-0 image. The meminfo provided by this is used by load_image() to
-validate whether the BL3-0 image can be loaded within the given
+SCP_BL2 image. The meminfo provided by this is used by load_image() to
+validate whether the SCP_BL2 image can be loaded within the given
memory from the given base.
-### Function : bl2_plat_handle_bl30() [mandatory]
+### Function : bl2_plat_handle_scp_bl2() [mandatory]
Argument : image_info *
Return : int
-This function is called after loading BL3-0 image and it is used to perform any
-platform-specific actions required to handle the SCP firmware. Typically it
+This function is called after loading SCP_BL2 image and it is used to perform
+any platform-specific actions required to handle the SCP firmware. Typically it
transfers the image into SCP memory using a platform-specific protocol and waits
until SCP executes it and signals to the Application Processor (AP) for BL2
execution to continue.
diff --git a/docs/trusted-board-boot.md b/docs/trusted-board-boot.md
index 1cfa843..cd999e5 100644
--- a/docs/trusted-board-boot.md
+++ b/docs/trusted-board-boot.md
@@ -66,7 +66,7 @@
* **Trusted world key**
The private part is used to sign the key certificates corresponding to the
- secure world images (BL3-0, BL3-1 and BL3-2). The public part is stored in
+ secure world images (SCP_BL2, BL3-1 and BL3-2). The public part is stored in
one of the extension fields in the trusted world certificate.
* **Non-trusted world key**
@@ -77,15 +77,15 @@
* **BL3-X keys**
- For each of BL3-0, BL3-1, BL3-2 and BL3-3, the private part is used to sign
- the content certificate for the BL3-X image. The public part is stored in
- one of the extension fields in the corresponding key certificate.
+ For each of SCP_BL2, BL3-1, BL3-2 and BL3-3, the private part is used to
+ sign the content certificate for the BL3-X image. The public part is stored
+ in one of the extension fields in the corresponding key certificate.
The following images are included in the CoT:
* BL1
* BL2
-* BL3-0 (optional)
+* SCP_BL2 (optional)
* BL3-1
* BL3-3
* BL3-2 (optional)
@@ -103,14 +103,15 @@
public part of the trusted world key and the public part of the non-trusted
world key.
-* **BL3-0 key certificate**
+* **SCP_BL2 key certificate**
It is self-signed with the trusted world key. It contains the public part of
- the BL3-0 key.
+ the SCP_BL2 key.
-* **BL3-0 content certificate**
+* **SCP_BL2 content certificate**
- It is self-signed with the BL3-0 key. It contains a hash of the BL3-0 image.
+ It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2
+ image.
* **BL3-1 key certificate**
@@ -139,8 +140,8 @@
It is self-signed with the BL3-3 key. It contains a hash of the BL3-3 image.
-The BL3-0 and BL3-2 certificates are optional, but they must be present if the
-corresponding BL3-0 or BL3-2 images are present.
+The SCP_BL2 and BL3-2 certificates are optional, but they must be present if the
+corresponding SCP_BL2 or BL3-2 images are present.
3. Trusted Board Boot Sequence
@@ -167,9 +168,9 @@
registers. If the comparison succeeds, BL2 reads and saves the trusted and
non-trusted world public keys from the verified certificate.
-The next two steps are executed for each of the BL3-0, BL3-1 & BL3-2 images. The
-steps for the optional BL3-0 and BL3-2 images are skipped if these images are
-not present.
+The next two steps are executed for each of the SCP_BL2, BL3-1 & BL3-2 images.
+The steps for the optional SCP_BL2 and BL3-2 images are skipped if these images
+are not present.
* BL2 loads and verifies the BL3-x key certificate. The certificate signature
is verified using the trusted world public key. If the signature
diff --git a/docs/user-guide.md b/docs/user-guide.md
index f921f87..b4ef37c 100644
--- a/docs/user-guide.md
+++ b/docs/user-guide.md
@@ -139,11 +139,11 @@
For more information on FIPs, see the "Firmware Image Package" section in
the [Firmware Design].
-2. (Optional) Some platforms may require a BL3-0 image to boot. This image can
+2. (Optional) Some platforms may require a SCP_BL2 image to boot. This image can
be included in the FIP when building the Trusted Firmware by specifying the
- `BL30` build option:
+ `SCP_BL2` build option:
- BL30=<path-to>/<bl30_image>
+ SCP_BL2=<path-to>/<scp_bl2_image>
3. Output binary files `bl1.bin` and `fip.bin` are both required to boot the
system. How these files are used is platform specific. Refer to the
@@ -180,8 +180,8 @@
#### Common build options
-* `BL30`: Path to BL3-0 image in the host file system. This image is optional.
- If a BL3-0 image is present then this option must be passed for the `fip`
+* `SCP_BL2`: Path to SCP_BL2 image in the host file system. This image is optional.
+ If a SCP_BL2 image is present then this option must be passed for the `fip`
target.
* `BL33`: Path to BL3-3 image in the host file system. This is mandatory for
@@ -327,8 +327,8 @@
specifies the file that contains the Non-Trusted World private key in PEM
format. If `SAVE_KEYS=1`, this file name will be used to save the key.
-* `BL30_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
- file that contains the BL3-0 private key in PEM format. If `SAVE_KEYS=1`,
+* `SCP_BL2_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the SCP_BL2 private key in PEM format. If `SAVE_KEYS=1`,
this file name will be used to save the key.
* `BL31_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
@@ -767,7 +767,7 @@
* putting the system into a known architectural state;
* taking care of platform secure world initialization;
-* loading the BL30 image if required by the platform.
+* loading the SCP_BL2 image if required by the platform.
When booting an EL3 payload on ARM standard platforms, the configuration of the
TrustZone controller is simplified such that only region 0 is enabled and is
@@ -1187,14 +1187,15 @@
### Preparing Trusted Firmware images
-The Juno platform requires a BL0 and a BL30 image to boot up. The BL0 image
-contains the ROM firmware that runs on the SCP (System Control Processor),
-whereas the BL30 image contains the SCP Runtime firmware. Both images are
-embedded within the Juno board recovery image, these are the files `bl0.bin`
-and `bl30.bin`.
+The Juno platform requires a SCP_BL1 and a SCP_BL2 image to boot up. The
+SCP_BL1 image contains the ROM firmware that runs on the SCP (System Control
+Processor), whereas the SCP_BL2 image contains the SCP Runtime firmware. Both
+images are embedded within the Juno board recovery image, these are the files
+`bl0.bin` and `bl30.bin`, respectively. Please note that these filenames still
+use the old terminology.
-The BL30 file must be part of the FIP image. Therefore, its path must be
-supplied using the `BL30` variable on the command line when building the
+The SCP_BL2 file must be part of the FIP image. Therefore, its path must be
+supplied using the `SCP_BL2` variable on the command line when building the
FIP. Please refer to the section "Building the Trusted Firmware".
After building Trusted Firmware, the files `bl1.bin` and `fip.bin` need copying