The hex conversion utility supports the secure flash boot capability provided by TMS320F2838x devices, which have both C28 and ARM cores. The secure flash boot applies the Cipher-based Message Authentication Protocol (CMAC) algorithm to verify CMAC tags for regions of allocated memory.
Secure flash boot is similar to the regular flash boot mode in that the boot flow branches to the configured memory address in flash. The difference is that this branch occurs only after the flash memory contents have been authenticated. The flash authentication uses CMAC to authenticate 16 KB of flash. The CMAC calculation requires a 128-bit key that you define. Additionally, you must calculate a golden CMAC tag based on the 16 KB flash memory range and store it along with the application code at a hardcoded address in flash. During secure flash boot, the calculated CMAC tag is compared to the golden CMAC tag in flash to determine the pass/fail status of the CMAC authentication. If authentication passes, the boot flow continues and branches to flash to begin executing the application. See the TMS320F2838x Microcontrollers Technical Reference Manual (SPRUII0) for further details about secure flash boot and the CMAC algorithm.
In order to apply the CMAC algorithm to the appropriate regions in allocated memory, use the hex conversion utility as follows:
The CMAC key in the file specified by the --cmac command-line option must use the format 0xkey0key1key2key3 in order to access the device registers for CMACKEY0-3. For example, the following file contents represent CMACKEY registers containing key0=0x7c0b7db9, key1=0x811f10d0, key2=0x0e476c7a, and key3=0x0d92f6e0.
0x7c0b7db9811f10d00e476c7a0d92f6e0
The CMAC feature uses four secure flash boot memory regions that are hardcoded for start/end/tag addresses, and one flexible CMAC region. The flexible region can encompass the entire allocated region as input in the HEX directive or user-specified start/end addresses defined in C code.
C code definitions like the following are required to reserve space for the CMAC tag symbols.
struct CMAC_TAG
{ char tag[8];
uint32_t start;
uint32_t end;
};
#pragma RETAIN(cmac_sb_1)
#pragma LOCATION(cmac_sb_1, 0x080002)
const char cmac_sb_1[8] = { 0 };
#pragma RETAIN(cmac_sb_2)
#pragma LOCATION(cmac_sb_2, 0x088002)
const char cmac_sb_2[8] = { 0 };
#pragma RETAIN(cmac_sb_3)
#pragma LOCATION(cmac_sb_3, 0x0a8002)
const char cmac_sb_3[8] = { 0 };
#pragma RETAIN(cmac_sb_4)
#pragma LOCATION(cmac_sb_4, 0x0be002)
const char cmac_sb_4[8] = { 0 };
#pragma RETAIN(cmac_all)
#pragma LOCATION(cmac_all, 0x087002)
const struct CMAC_TAG cmac_all = { 0 }, 0x0, 0x0};
The four secure flash boot region CMAC tags are stored in the cmac_sb_1 through cmac_sb_4 symbols. The cmac_all symbol stores the CMAC tag for the flexible user-specified region. For cmac_all:
RETAIN pragmas are required in the C code if these symbols are not accessed in the application code.
LOCATION pragmas are required to place symbols at the required memory locations. The LOCATION entries for cmac_sb_1 through cmac_sb_4 are at fixed addresses. The LOCATION address for cmac_all can be user-specified. However, it must not be located within any secure flash boot regions, because the ROM CMAC implementation on the devices does not support this.
The CMAC algorithm is applied prior to the hex conversion. No changes are made to the original input ELF executable.
The hex conversion utility applies the CMAC algorithm only to CMAC regions that have global symbols defined. So if an ELF executable defines only cmac_sb_1 and cmac_all, then only those two CMAC tags will be generated and populated in the generated hex output file.