makefile_ccs_bootimage_gen
that is included in every example and secondary bootloader (SBL) CCS project.makefile
in the example folder.This section describes the various tools that are used to create boot images for all the SDK applications
Folder/Files | Description |
---|---|
${SDK_INSTALL_PATH}/tools/boot/ | |
multicoreImageGen/ | Tool to combine multiple RPRC into a single binary |
out2rprc/ | Tool to convert compiler generated ELF .out for a CPU to a compact and loadable binary representation, called RPRC. |
sbl_prebuilt/ | Pre-built secondary bootloader (SBL) images and flash configuration files for different supported EVMs, see also Flashing Tools |
signing/ | Security signing scripts need to create boot images that can be booted by ROM bootloader (RBL) |
uart_bootloader.py | Python script used to send the SBL and appimage binaries over UART using XMODEM protocol in UART boot mode |
uart_uniflash.py | Python script used to flash SBL and applications to EVM flash using UART. See Flashing Tools for more details. |
MulticoreImageGen
tool that generates the final binary that is flashed (*.appimage
)0x43525052
- which is ASCII equivalent for RPRC
0x5254534D
- which is ASCII equivalent for MSTR
.appimage
file DEV_ID
is 55
.CORE | CORE ID |
---|---|
r5fss0-0 | 0 |
r5fss0-1 | 1 |
c66xdsp_0 | 2 |
openssl
installed as mentioned here, OpenSSLFor SBL images, the script /tools/boot/signing/mcu_rom_image_gen.py
.
For HS-FS devices:
For HS-SE devices:
Here, we deep dive into the extension supported in SBL and HSM Runtime (TIFS-MCU) certificate by ROM. To get access to the HSM Runtime code and ability to build it for HS-SE device, please contact your TI represntative to get access to the TIFS-MCU package from MySecureSW.
The Boot Information Object identifier provides information about the image which is being loaded. This information is mandatory and needs to be present else the image boot will fail.
Certificate Type: The certificate type defines the type of the image which is being loaded by the Boot-ROM.
These are the supported values:
Boot core: The boot core identifies the core on which the image will be executing.
These are the supported values:
Core Options: The core options are documented in the table below.
These are the supported values:
Core options are applicable only for the R5 SBL Images.
Load Address: The load address will be address in the system where the image will be loaded. This is applicable for both SBL and TIFS-MCU (HSMRt) images.
Image Size: This is the size in bytes of the R5 SBL or HSM Runtime Image to which the certificate has been attached.
If the X.509 certificate provides the image integrity boot extension, the Boot-ROM will perform the SHA-512 on the entire image and will verify the computed hash with the hash provided in the boot extension. In the case of a mismatch the boot will fail.
SHA Type: The Boot-ROM only supports SHA-512.
The following values are supported:
2.16.840.1.101.3.4.2.3 SHA-512 Object Identifier
Please refer to the Section 2.4 of the RFC-5754 for the SHA-512 Object Identifier.
Hash: This is SHA-512 hash which is calculated over the image (R5 SBL/HSM Runtime)
R5 SBL Image:
HSM Runtime Image:
The information in the software revision is used to indicate the version of the image which is being loaded.
revision: This is the version number. This will be matched to the EFUSE programmed version to indicate if the image loading should be done or not. This is applicable only for SE devices.
EFUSE Revision | Certificate Revision | Description |
---|---|---|
0 | 0 | Ignore the revision checking. Images will always be loaded |
0 | >0 | Device does not mandate revision checking. Images will be loaded |
>0 | 0 | EFUSE Version > Certificate Version. Image will never be loaded. |
>0 | >0 | Image will be loaded only if the Certificate revision >= EFUSE revision |
The following fields in efuse ROM help support the above feature:
For more information, about how to fuse in these values, please refer to OTP Keywriter Documentation available on MySecureSW.
The Boot-ROM only supports AES-CBC mode with 256bit keys. The information in the image encryption object identifier is used to decrypt the image.
IV: The initialization vector is used during the AES-CBC decryption procedure. The initialization vector needs to be 16bytes.
rs: This is the random string which is 32bytes long and is appended by the script at the end of the image. The Boot-ROM will decrypt the image and will perform a random string comparison to determine if the decryption was successful.
iter: Iteration Count which is used to determine if the HKDF needs to be performed and key derivation needs to be done. If the iteration count is 0 then the key from the e-fuse is used as is for the decryption. If the iteration count is non-zero then the Boot-ROM will perform the HKDF key derivation using the salt with exactly one iteration (even if iteration count is > 1). The derived key is then used for the decryption operation.
salt: The salt is used only if the iteration count is non-zero and key derivation is being done. The salt is fed to the HKDF module to derive the key. The salt fields should be 32bytes.
For recommendation on the salt, please refer to Enabling Secure Boot.
The Boot-ROM will leave a derived key in the assets interface for the TIFS-MCU. The key is derived using HKDF from the parameters specified here. This is useful for decrypting application images by sending request to TIFS-MCU. For recommendation on the salt, please refer to Enabling Secure Boot.
salt: The salt is limited to be 32bytes and is used for key derivation
This OID is ignored as part of HSM Runtime certificates. This OID is ignored as part of SBL certificates if the device type is HS-FS. Key derivation is always done using the active user symmetric key.
The debug object identifier if specified allows the debug ports to be enabled for a specific device.
UID: This is the unique identifier associated with the device. Device specific unique identifiers can be retrieved using the SOC_ID Parser.
The UID field of all 0s is considered to be a wildcard. This is what is supported by default in the script.
Debug Type: This is the privilege level of debug.
The privilege levels supported by ROM are as follows:
Privilege Level | Value | Description |
---|---|---|
DBG_PERM_DISABLE | 0 | Disable debug ports for all cores. |
DBG_SOC_DEFAULT | 1 | Maintain debug ports for all cores to device type defaults. |
DBG_PUBLIC_ENABLE | 2 | Enable debug ports on R5FSS0-0 core. |
coreDbgEn and secCoreDbgEn: These fields are not used and will be ignored.
In the SBL Signing scripts, DEBUG_OPTION
is used to exercise the debug level if the SBL certificate has debug extension. The SBL certificate as mentioned before, is processed by ROM. This is different from the debug certificate supported by TIFS-MCU.
This feature is leveraged via compile time flags in MCU+ SDK for SBL images.
By default, in SDK, the debug extension is not engaged for SBL images. This is decided by the flag DEBUG_TIFS
defined in devconfig.mak
. By default, DEBUG_TIFS
is set to yes
.This means that the debug extension will not be added to SBL and if the debug needs to be exercised via the certificate to TIFS-MCU via the debug authentication service, it can be safely done. This is done to ensure that the registers are written once only to exercise the debug during a POR cycle. If the user wants to open up debug on an HS-SE device, they can set DEBUG_TIFS=no
. This is when the debug extension is added to the certificate for SBL images.
DEBUG_TIFS
i.e. yes
when compiling SBL examples.The default debug privilege used in SDK is DBG_SOC_DEFAULT
.
To enable debug on public cores on HS-SE device, one can use the following command to compile SBL examples.
These scripts are invoked in makefiles, and the image generation happens automatically along with the example build. So mostly these scripts need not be manually run. If the user build-system is different from TI's makefile system, it needs to be ensured that the same is followed as part of the post build steps. The devconfig has ENC_SBL_ENABLED=yes and that is why for HS-SE devices, the SBL image is encrypted by default.
For Application images, the script /tools/boot/signing/mcu_appimage_x509_cert_gen.py
.
For HS-SE devices:
Signing of application images is not required for HS-FS device types.
Here, we deep dive into the extension supported with certificate for Application images as processed by TIFS-MCU. To get access to the HSM Runtime code and ability to build it for HS-SE device, please contact your TI represntative to get access to the TIFS-MCU package from MySecureSW.
The Boot Information Object identifier provides information about the image which is being loaded.
Certificate Type: The certificate type defines the type of the image which is being loaded by the Boot-ROM.
These are the supported values:
Boot core: This field is reserved and should be assigned with 0.
Core Options: This field is reserved and should be assigned with 0.
Load Address: This field is reserved and should be assigned with 0.
Image Size: This is the size in bytes of the R5 SBL or HSM Runtime Image to which the certificate has been attached.
If the X.509 certificate provides the image integrity boot extension, the TIFS-MCU will perform the hash calculation on the entire image and will verify the computed hash with the hash provided in the boot extension. In the case of a mismatch the boot will fail.
SHA Type:
The following values are supported:
Amongst these, SDK has been validated against SHA-512 OID.
Hash: This is SHA-512 hash which is calculated over the application image
The information in the software revision is used to indicate the version of the image which is being loaded.
revision: This is the version number. This will be matched to the EFUSE programmed version to indicate if the image loading should be done or not.
The following fields in efuse ROM help support the above feature:
For more information, about how to fuse in these values, please refer to OTP Keywriter Documentation available on MySecureSW.
TIFS-MCU only supports AES-CBC mode with 256bit keys. The information in the image encryption object identifier is used to decrypt the image.
IV: The initialization vector is used during the AES-CBC decryption procedure. The initialization vector needs to be 16bytes.
rs: This is the random string which is 32bytes long and is appended by the script at the end of the image. TIFS-MCU will decrypt the image and will perform a random string comparison to determine if the decryption was successful.
iter: This field is unused and reserved.
salt: This field is unused and reserved.