diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/auth-framework.md | 7 | ||||
| -rw-r--r-- | docs/firmware-design.md | 24 | ||||
| -rw-r--r-- | docs/porting-guide.md | 48 | ||||
| -rw-r--r-- | docs/trusted-board-boot.md | 29 | ||||
| -rw-r--r-- | docs/user-guide.md | 31 |
5 files changed, 71 insertions, 68 deletions
diff --git a/docs/auth-framework.md b/docs/auth-framework.md index b910eaeb..f6455b9e 100644 --- a/docs/auth-framework.md +++ b/docs/auth-framework.md @@ -211,8 +211,9 @@ It is responsible for: 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 @@ is, however, a minimum set of images that are mandatory in the Trusted Firmware 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 41fb7c0d..51084f45 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -248,16 +248,16 @@ BL2 also initializes a UART (PL011 console), which enables access to the 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 @@ The following list describes the memory layout on the ARM development platforms: * 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 @@ layout of the other images in Trusted SRAM. 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 @@ layout of the other images in Trusted SRAM. 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 b77377f1..5e80a7ff 100644 --- a/docs/porting-guide.md +++ b/docs/porting-guide.md @@ -277,23 +277,23 @@ also be defined: 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 @@ The BL2 stage is executed only by the primary CPU, which is determined in BL1 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 @@ copied structure is made available to all BL2 code through the 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 @@ populated with the extents of secure RAM available for BL2 to use. See `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 1cfa843d..cd999e5c 100644 --- a/docs/trusted-board-boot.md +++ b/docs/trusted-board-boot.md @@ -66,7 +66,7 @@ The keys used to establish the CoT are: * **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 @@ The keys used to establish the CoT are: * **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 @@ The following certificates are used to authenticate the images. 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 @@ The following certificates are used to authenticate the images. 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 @@ if any of the steps fail. 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 f921f87a..b4ef37c2 100644 --- a/docs/user-guide.md +++ b/docs/user-guide.md @@ -139,11 +139,11 @@ Trusted Firmware source tree and follow these steps: 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 @@ performed. #### 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 @@ performed. 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 @@ complexity of developing EL3 baremetal code by: * 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 @@ deliverables on Juno][Juno Instructions]. ### 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 |