The MCU+SDK supports only HS-FS (High Security - Field Securable) in the SDK This document aims to list out the differences between the GP and HS-FS device types and aid the users to develop on HS-FS device type.
One of the major differences between GP and HS-FS is System Firmware (TIFS). In both devices, TIFS is always signed with an asymmetric key (RSA/ECC) and wrapped in the resulting x509 certificate. In case of GP, the key used for signing is not verified by ROM, so usually a degenerate key is used. In case of HS-FS device, TIFS will be encrypted with TI encryption key (TI MEK) and signed with TI asymmetric key (TI MPK). The SDK will contain the encrypted and signed binary.
In case of example applications other than SBL (hello_world, dpl_demo etc...) the same application image file (*.appimage
) should be signed with ROM degenerate key to boot from HS-FS device.
In case of SBL applications (sbl_sd, sbl_ospi, sbl_null etc...) since SDK follows combined boot flow, TIFS is packaged along with the sbl final image (*.tiimage
). Since the TIFS is different between GP and HS-FS, the sbl final image also will change. This is taken care through an additional keyword in the file extension, **'hs_fs'**. The *.tiimage
would now become *.hs_fs.tiimage
For example in the case of sbl_ospi
, with release build profile, the final image in the case of GP device type would be
sbl_ospi.release.tiimage
(Same as before)In case of HS-FS device type, it would be
sbl_ospi.release.hs_fs.tiimage
HS-FS images will be built when you build SBLs for GP device itself, so no extra build options are required to be passed.
Since most of the differences in HS-FS is related to image signing, once the SBL and application image is correctly built, rest of the flow is the same as GP for application boot. Take care that the right images are used. For example, to use SBL NULL for you application boot, flash the sbl_null.release.hs_fs.tiimage
image. Same goes for other SBLs.
Entity | GP | HS-FS |
---|---|---|
TIFS image | Plain (tifs.bin ) | Signed and encrypted with TI Key (tifs-hs-fs-enc.bin , tifs-hs-fs-enc-cert.bin ) |
Application image name | *.appimage | *.appimage.hs_fs (eventually) |
SBL image name | *.tiimage | *.hs_fs.tiimage |
CCS + GEL flow bootmode | NO-BOOT recommended, any bootmode functional | DEV-BOOT mode mandatory |
CCS + GEL flow js script | load_dmsc.js | load_dmsc_hs_fs.js |
SBL images and non-SBL example application images use different signing scripts. This is due to the difference in the x509 certificate format expected by ROM and TIFS. These differences and scripting is already part of SDK makefiles, but in case if the user has their own build system and wants to integrate these steps into it, please go through this section. The signing scripts used are python3 based.
TIFS is not signed with SDK signing scripts. Pre-encrypted TIFS binaries with x509 certificate binary generated as a result of signing with the TI keys is part of the SDK.
To create the x509 certificate header-ed SBL image, the script used is rom_image_gen.py
. This is located in ${SDK_ROOT}/tools/boot/signing
. The usage of the script will be printed if you run it with -h
option like so:
The script is usually run after the sbl binary is created using an objcopy utility. That is a *.bin
file. In GP, we sign the binary using a degenerate key. We also pass the GP TIFS binary and the boardcfg binary to the signing script. Here is an example of how it's done in GP for say sbl_ospi
.
In the options mentioned here, the values used for TIFS load address (--tifs-loadaddr
), BoardCfg load address (--bcfg-loadaddr
) and SBL load address (--sbl-loadaddr
)are fixed for an SoC, so no need to change. Notice how just the TIFS binary is passed in case of GP. This is an unsigned, unencrypted binary.
In case of HS-FS device, we use the same signing script, but there is a small difference in the usage.
You can see that we are involving the x509 certificate for the HS-FS TIFS binary in the image creation. This is the major difference in the SBL image creation of HS-FS devices. You would observe that the other parameters are pretty much the same between both cases.
Signing for the application image is new in HS-FS compared to GP. For the signing of application images we use a different script. This is because authentication of application images are done by TIFS and it expects a different x509 certificate format. For signing application images, the script used in appimage_x509_cert_gen.py
located at ${SDK_ROOT}/tools/boot/signing/
. The usage of the script will be printed if you run it with -h
option like so:
Usage of the signing script in HS-FS is fairly simple compared to the SBL signing script. Here is a typical usage for hello_world
example:
Note that the key used for signing is rom degenerate.