Design Article

An efficient and integrated bootloader solution for portable multimedia systems, Part 2

Vignesh A. Loganthan, and Biju M. Gopinath, Texas Instruments

3/9/2007 11:46 AM EST

Part 1 of this two-part article describes different boot modes and market needs which drive these requirements. This second part deals with security features of the boot loaders, application scenarios to support fast booting of the devices, and the key benefits of this integrated boot solution.

Secure boot modes
One striking advantage of TI DM processors is the DSP processors which form a part of the multi-core SoCs. The DSP in addition to the media processing, becomes useful during the boot up and the ARM RBL uses the DSP Secure kernel intelligently to boot the applications and devices where security becomes very critical. Today we have several security critical functions like online download, DRM (Digital Rights management), firmware upgrade etc., and Secure boot is a key differentiator in this unified RBL approach.

The central heart of this system is a secure software kernel residing in the DSP ROM. For all secure devices the DSP will be forced to boot from this ROM to ensure all security aspects of the DSP. During secure boot mode, ARM and DSP work together and efficiently utilize the system resources. ARM reads the encrypted UBL data into ARM internal memory and requests DSP to decrypt the data. DSP checks for the appropriate signature based on the keys and decrypt the data in-place. ARM will then pass control to the decrypted UBL for execution.

The Inter-Processor Communications (IPC) between the ARM and DSP cores takes place through a shared communications region located in DSP internal RAM. Additional signaling is performed through ARM and DSP interrupts. The layout of this region is:

struct SHM_control {
    volatile unsigned int magicId; /* magic ID number */
    volatile unsigned short gppMsgNum; /*GPP message number */
    volatile unsigned short cmdCode; /* requested DSP service code */
    volatile unsigned int arg[2]; /* service call arguments */
    volatile unsigned short dspMsgNum; /* DSP message number */
    volatile unsigned short completionCode; /* DSP request completion code */
};

The sequence of operations during a secure boot is captured below.

  • When the DSP comes out of reset the Secure Boot sequence sets up the initial state of the DSP.
  • Upon completion of this sequence, the DSP clears the shared memory control area and sets the magidId field to 0xAA55BEEF.
  • Next it activates the ARM interrupt to notify the ARM that the DSP initialization is complete, and the DSP is in the Secure Loader mode state.
  • The gppMsgNum and dspMsgNum fields initially start out at 0. Whenever these two fields are identical, the DSP is waiting for a request from the ARM.
  • ARM initiates a service request by setting the cmdCode, and argument fields of the shared memory structure.
  • Next it increments the gppMsgNum field and sends an interrupt to the DSP.
  • The DSP then services the request, sets the appropriate completion code in the completionCode field, and copies the gppMsgNum field to the dspMsgNum field
  • Finally the DSP activates the ARM interrupt to notify the ARM that the request has been completed, and the completion code field is now valid.

The Secure Loader support routines perform the following functions:

  • Verify key hash and descriptor signature
  • Decrypt memory region with either Key Encryption Key or Customer Encryption Key

Next: Secure boots




Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)