6 C2000Ware Example Details

In C2000Ware [2], an example is provided to show an application setup for secure flash boot. The example includes secure flash boot application projects for each core. The example additionally details how to authenticate flash code beyond the secure flash boot entry address + 16KB. More details on this custom flash range authentication functionality are explained in the Section 7. This example assumes that the flash sectors to be authenticated are pre-configured as Zone 1 EXEONLY and uses the default CMACKEY for authentication. For details on programming a custom CMACKEY and other DCSM settings in CPU1 USER OTP, see [1] and [2].

C2000Ware Location: <C2000Ware_Install_Directory>/driverlib/f2838x/examples/c28x/boot

Project Names:

• boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1
• boot_ex1_cpu1_cpu2_cm_secure_flash_cpu2
• boot_ex1_cpu1_cpu2_cm_secure_flash_cm

Files Included:

• Source files – Includes main application code
  • Example: boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1.c
• HEX Linker Command files – Provides details of the entire length of flash memory to the c2000 or arm hex utility
  • Example: boot_ex1_flash_hex_lnk_cpu1.cmd
• CMAC key text file – Provides the user CMAC key to the c2000 or arm hex utility
  • Example: boot_ex1_user_cmac_key.txt
  • For more details on the cmac_key format, see [3] and [4].

How to run the example:

1. Load application into CPU1 flash (as well as CPU2 and CM applications).
   1. Load the *.hex file, not the *.out file
2. Disconnect and reconnect to only CPU1.
3. To configure the device to perform secure flash boot upon boot up:
   1. Emulation boot (recommended for example/development)
      1. In CCS memory window, set BOOTPINCONFIG location (0x0D00) to 0x5AFFFFFF and BOOTDEF location (0x0D04) to 0x0000000A
   2. Standalone boot (recommended for deployment)
      1. Program CPU1 USER OTP locations corresponding to BOOTPINCONFIG and BOOTDEF. To learn more, see [1].
4. Reset CPU1 via CCS and click resume.
5. Observe the LEDs on the controlCARD for indicators of success.
   1. When all three cores secure boot successfully and authenticate their full flash memory contents, then three LEDs (one for each core) will be blinking.
6. For cases where the controlCARD isn’t used, look out for the following GPIO toggles based on the CPU subsystem:
   1. CPU1 – GPIO31
   2. CPU2 – GPIO34
   3. CM – GPIO145

Application code requirements for golden CMAC Tag generation:

CPU1/CPU2 Golden CMAC Tag Memory Allocation for Secure Flash Boot Option 0

// Implementation for CPU1/CPU2
#pragma RETAIN(cmac_sb_1)
#pragma LOCATION (cmac_sb_1, 0x080002)
const char cmac_sb_1[8] = {0};

CM Golden CMAC Tag Memory Allocation for Secure Flash Boot Option 0

#pragma RETAIN(cmac_sb_1)
#pragma LOCATION (cmac_sb_1, 0x00200004)
const uint8_t cmac_sb_1[16] = {0};

Constant char/unsigned integer definitions allocate memory for golden CMAC tags. For more information, see the examples in Section 6:

• Variable naming must be one of the following: cmac_sb_1, cmac_sb_2, cmac_sb_3, cmac_sb_4
  • Further details for C28x can be found in the TMS320C28x Assembly Language Tools User's Guide [3]
  • Further details for CM can be found in the ARM Assembly Language Tools User's Guide [4].
• Use the LOCATION pragma to specify the address within the intended authentication range for the CMAC golden tag. For CPU1/CPU2, this address must be the entry address + 2 and for CM, this address must be the entry address + 4.
• Leave the variable initialized to zero.

Application setup for using HEX Utility:

Each core project enables the hex utility to generate the golden CMAC tag (see Figure 6-1). Flags include:

• “--cmac” provides the path to the user CMAC key text file
• “--image”, “--memwidth”, and “--romwidth” where mem/rom width is set. This should be set to 16 for CPU1/CPU2 and set to 8 for CM
• The paths to the flash HEX linker command file for the corresponding core.