The purpose of the initial programming
flow is to setup a blank device in order to be able to run a trusted vendor
application upon reset.
- May be done as needed at the
vendor R&D to “reformat” the flash or add capabilities by programming
additional fuse based capabilities (e.g. authentication bypass
disable/authentication enable - which is highly recommended for deployed
devices).
- Suitable for production lines to pre-program deployed devices.
The CC35xx device executes the boot
sequence for initial programming in multiple stages through the full Chain of Trust.
A detailed description of the flow is as follows:
- Flow execution upon special reset triggered through the debug I/F.
- BL1 loads, authenticates and invokes BL2 into the co-processor from the debug
I/F.
- BL2 Identifies that the device was activated already
- BL2 Identifies the request as a signed programming request
- BL2 Authenticates the signed programming request (unique per device) using the
public key whose hash matches the one installed during the one-time activation.
- Once authenticated, BL2 performs the programming instructions for programming
fuses and configuring the external flash for programming of images based on the
vendor programming instructions provided over the debug I/F.
- Then BL2 programs to the flash the images that the vendor issues over the debug
I/F. For successful initial programming the flash must contain the following:
- Boot sector
- TI bootloader (BL2) image (signed by TI)
- Wireless Connectivity FW image (signed by TI)
- Vendor image (signed by the vendor)
- BL2 issues a report to indicate success or failure of the process
After successful initial programming,
upon reset, the device executes the programmed vendor image in a trusted manner
after running the Application Execution Boot Flow.