J722S MCU+ SDK  09.02.00
HS FS Migration Guide

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.

System Firmware

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.

TIFS in HS-FS device

NON-SBL Example Appimage Build

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.

SBL Application Build

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.

Application boot using SBL (SBL OSPI, SBL NULL, SBL UART, SBL SD etc.)

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.

Summary of differences in GP vs HS-FS

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

Signing of Images in GP vs HS-FS

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 Signing

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.

SBL Signing

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:

$ python3 rom_image_gen.py -h
usage: rom_image_gen.py [-h] [--swrv SWRV] --sbl-bin SBL_BIN [--sbl-enc] [--enc-key ENC_KEY] --tifs-bin
TIFS_BIN [--tifs-inner-cert TIFS_INNER_CERT] --boardcfg-blob BOARDCFG_BLOB
--sbl-loadaddr SBL_LOADADDR --tifs-loadaddr TIFS_LOADADDR --bcfg-loadaddr
BCFG_LOADADDR --key KEY --rom-image ROM_IMAGE [--debug DEBUG]
Creates a ROM-boot-able combined image when the SBL, TIFS and BoardCfg data are provided
optional arguments:
-h, --help show this help message and exit
--swrv SWRV Software revision number
--sbl-bin SBL_BIN Path to the SBL binary
--sbl-enc Encrypt SBL or not
--enc-key ENC_KEY Path to the SBL Encryption Key
--tifs-bin TIFS_BIN Path to the tifs binary
--tifs-inner-cert TIFS_INNER_CERT
Path to the tifs inner certificate
--boardcfg-blob BOARDCFG_BLOB
Path to the boardcfg blob
--sbl-loadaddr SBL_LOADADDR
Load address at which SBL needs to be loaded
--tifs-loadaddr TIFS_LOADADDR
Load address at which TIFS needs to be loaded
--bcfg-loadaddr BCFG_LOADADDR
Load address at which BOARDCFG needs to be loaded
--key KEY Path to the signing key to be used while creating the certificate
--rom-image ROM_IMAGE
Output file combined ROM image of SBL+TIFS+Boardcfg
--debug DEBUG Debug options for the image

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.

$ python3 rom_image_gen.py --swrv 1 --sbl-bin /path/to/sbl_ospi.release.bin --tifs-bin /path/to/tifs.bin --boardcfg-blob /path/to/boardcfg_blob.bin --sbl-loadaddr 0x43C40000 --tifs-loadaddr 0x40000 --bcfg-loadaddr 0x67000 --key /path/to/rom_degenerateKey.pem --rom-image /path/to/sbl_ospi.release.tiimage

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.

$ python3 rom_image_gen.py --swrv 1 --sbl-bin /path/to/sbl_ospi.release.bin --tifs-bin /path/to/tifs-hs-fs-enc.bin --tifs-inner-cert /path/to/tifs-hs-fs-enc-cert.bin--boardcfg-blob /path/to/boardcfg_blob.bin --sbl-loadaddr 0x43C40000 --tifs-loadaddr 0x40000 --bcfg-loadaddr 0x67000 --key /path/to/rom_degenerateKey.pem --rom-image /path/to/sbl_ospi.release.hs_fs.tiimage

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.

Appimage Signing

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:

python3 appimage_x509_cert_gen.py -h
usage: appimage_x509_cert_gen.py [-h] [--bin BIN] [--key KEY] [--enckey ENCKEY] [--cert CERT] [--output OUTPUT] [--core CORE] [--enc ENC] [--loadaddr LOADADDR] [--authtype AUTHTYPE]
Generates a x509 certificate for an application binary to boot it in HS device
optional arguments:
-h, --help show this help message and exit
--bin BIN Bin file that needs to be signed
--key KEY File with signing key inside it
--enckey ENCKEY File with encryption key inside it
--cert CERT Certificate file name (optional, will use a default name otherwise)
--output OUTPUT Output file name (concatenated cert+bin)
--core CORE Core on which the binary is meant to be loaded. Optional
--enc ENC If the binary need to be encrypted or not [y/n]
--loadaddr LOADADDR Target load address of the binary in hex. Default to 0x70000000
--authtype AUTHTYPE Authentication type. [0/1/2]. 0 - Move to destination address specified after authentication, 1 - In place authentication, 2 - Move to the certificate start after authentication. Default is 1

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:

$ python3 appimage_x509_cert_gen.py --bin /path/to/hello_world.release.appimage --authtype 1 --key /path/to/rom_degenerateKey.pem --output /path/to/hello_world.release.appimage.hs_fs

Note that the key used for signing is rom degenerate.