• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 244 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRA821U: Hardware requirements for burning Secure Boot keys

Steve Turza
Intellectual 280 points
Part Number: DRA821U


Tool/software:

We are designing a product using the DRA821U processor, and we intend to use Secure Boot.
During our production process we would need to individually burn our private key into each unit.
The only documented procedure that I can see to do this is to use USB-DFU boot (& Keywriter),
but we are already using USB in host mode for an onboard device.
The procedure also mentions booting in UART mode to verify the burning of the key, again this is a hardware
cost / real estate I do not want to support if optional.
Can you please answer the following questions...

1/ What CPU boot modes would I need to support for Keywriter ?
2/ Is support for UART boot mode optional ?
3/ I understand that I would need to provide VPP_MCU & VPP_CORE during this step.
The DRA821U eval board uses a GPIO from PMIC "B" to enable the 1.8V LDO, but I have a single PMIC design.
What GPIO should I use instead?
4/ Is there any other method to burn the key into the processor?
5/ I have read "sprad04.pdf". Is there any more instructions / documentation that would help me with my design?

Thanks,
Steve

  • 0
    TI__Guru** 113435 points

    Hi Steve,

    Steve Turza said:
    The only documented procedure that I can see to do this is to use USB-DFU boot (& Keywriter),

    Hmm, where are you seeing this? This is not true.

    Steve Turza said:
    1/ What CPU boot modes would I need to support for Keywriter ?

    The overall KeyWriter application is like a Bootloader, so you can technically run it in any standard bootmode that your board supports. The UART or the USB are the typical peripheral based boot-modes that doesn't require the keywriter application to be flashed onto some boot media.

    Steve Turza said:
    2/ Is support for UART boot mode optional ?

    The supported boot-modes are a board decision choice, so it depends on what boot modes are supported by your board. There is always a primary boot-mode and an optional backup boot-mode. UART boot mode is one of the typical backup boot-modes as a storage media boot mode is the typical primary boot-mode.

    Steve Turza said:
    3/ I understand that I would need to provide VPP_MCU & VPP_CORE during this step.
    The DRA821U eval board uses a GPIO from PMIC "B" to enable the 1.8V LDO, but I have a single PMIC design.
    What GPIO should I use instead?

    Correct. This really depends on your PDN solution, and how you are controlling and supplying the VPP_MCU & VPP_CORE. Are you using a discrete LDO to control these or directly controlling these through the PMIC?

    Steve Turza said:
    4/ Is there any other method to burn the key into the processor?

    Please see my response on #1. It really depends on what boot-modes your board is supporting, and what boot-media you are using for boot. 

    Steve Turza said:
    5/ I have read "sprad04.pdf". Is there any more instructions / documentation that would help me with my design?

    sprad04.pdf is the Jacinto7 HS Device Development Application Note.

    You can also see the Jacinto7 HS Device Flashing Solution Application Note, which does explain using the primary offset and backup offsets in NOR Flash to have a KeyWriter and a regular boot binary.

    regards

    Suman

  • 0 in reply to Suman Anna
    Intellectual 280 points

    Suman,

    Thanks for the quick response.

    Based upon your information, I would like to run through a scenario on how our production procedure will work;

    i/ Primary boot mode will be eMMC which is pre-programmed with our final secure u-boot & image.

    ii/ Secondary boot mode will be SD_Card   !!OR!!    MCU_UART.

    iii) At the first power-up primary boot mode is temporarily disabled with a jumper, forcing secondary boot mode.

    iv) Keywriter program is loaded and executed via SD_Card  !!OR!! MCU_UART via XMODEM.

    I also have 3 further questions:

    1/ Please confirm that u-boot is not required for Keywriter.

    2/ How do I configure the GPIO that I use to control VPP_MCU & VPP_CORE ? Is that somehow configured when building Keywriter image ?

    3/ Is my public key exposed during any part of this process? Can someone extract my private key from the Keywriter image ?

    Thanks,

    Steve

  • 0 in reply to Steve Turza
    TI__Guru** 113435 points

    Hi Steve,

    Steve Turza said:
    1/ Please confirm that u-boot is not required for Keywriter.

    Correct, U-Boot is not required for KeyWriter.

    Steve Turza said:
    2/ How do I configure the GPIO that I use to control VPP_MCU & VPP_CORE ? Is that somehow configured when building Keywriter image ?

    Yes, this is part of the KeyWriter application. You are expected to adjust the code matching your PDN solution.

    Please see the Important Features & Details section of the 4.17. OTP KEYWRITER module in the PDK documentation.

    Steve Turza said:
    3/ Is my public key exposed during any part of this process? Can someone extract my private key from the Keywriter image ?

    No, the KeyWriter process uses encryption on the public key hashes during the certificate generation process.

    Private key cannot be extracted from the KeyWriter image.

    regards

    Suman

  • 0 in reply to Steve Turza
    TI__Guru** 113435 points

    Hi Steve,

    Steve Turza said:
    Based upon your information, I would like to run through a scenario on how our production procedure will work;

    Your overall sequence is ok and outlines the generic steps except for possibly Step iii.

    Steve Turza said:
    iii) At the first power-up primary boot mode is temporarily disabled with a jumper, forcing secondary boot mode.

    The primary boot mode cannot be disabled in general. Do you mean that your bootmode would be set to some other invalid mode other than eMMC, rendering the ROM to fall back onto the Secondary boot mode.

    regards

    Suman