During the boot flow, the container is parsed and programmed to the device. The different binaries are checked for authenticity against a root-of-trust public key that exists in ROM, and the matching private key is located on Texas Instruments servers.

Section 3.1.2 illustrates the boot flow.

Figure 3-2 CC33xx Boot Flow

The boot flow is divided into two main phases, the ROM boot mode and the RAM boot mode. The logic behind this is to enable flexibility where the bootloader phase can be modified in case of detected bugs or added features but without compromising on security. Both bootloader sections are considered as running in privileged secure mode.

As part of the ROM bootloader phase, hardware is initialized. This step includes clock detection, PLL lock, fuse bits validation and more. Next is testing the mode or life cycle of the device. In most cases, the device are operational in functional mode but there are cases where the device can be in debug mode, test mode or some kind of failure mode. These modes are not covered in this document. Lastly on the ROM bootloader section, the RAM bootloader binary is delivered from the host processor in chunks and placed in the target location in RAM. This is done only after the binary is decrypted and authenticated against the root-of-trust public key. When this phase is over, an appropriate event is generated and propagated to the host processor.

As part of the RAM bootloader, similar procedure is done but this time with the rest of the binaries, including the Wi-Fi/Bluetooth Low Energy MAC firmware, the Wi-Fi PHY firmware and the Bluetooth Low Energy PHY firmware. When this phase is over, an appropriate event is generated and propagated to the host processor. At this point, the firmware is running and ready to get commands and data from the host processor.