• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 553 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.

OMAP L138 secure bootup

frank handal
Prodigy 40 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

 

We are attempting to bring up our first secure OMAPL138. We have followed the Generic_Security_Users_Guide,

and are utilizing SecureHexAIS_OMAP-L138.exe & Secure UART Boot Host tools.

 

We have a binary that we know already works.

We produced an AIS file, and are able to get secure boot to progress to "Waiting for DONE" then it just hangs (see attached).

 

 

Here are our questions:

 

* Can we generate bin file with signature only, and download via Secure UART Boot Host?

 

* If yes, why don't we get DONE? (see attached)

 

Most Important:

  We need to understand how to utilize the Secure Kernel API so that we can enable the JTAG, and perform other operations.

  • 0
    TI__Prodigy 490 points

    Frank,

      Unfortunately, I was not able to get your attachment.   If you could try to re-attach, I would appreciate it.

      First, please make sure you are loading all of your code in to L2 because L1 is cache during secure boot.  Also note that the first 32 bytes of L2 are reserved if you execute SK_switchNonSec().

      In order to enable JTAG, you need to use the SK_setJTAGControl( control_word) function in the secure kernel APIs.  The control word is a 32 bit value with ones for all the TAPs you would like enabled.  The easiest way to open the entire chip is to write 0xFFFFFFFF. 

      Hopefully that gets you started, please let me know if there are other questions.

    Thanks,

    Erik

  • 0 in reply to Erik Welsh
    Prodigy 40 points

    Erik,

     

    Thank you for the original response, however like expected here is some more details from my customer in regards to where they are stuck now.  Would it be possible to communicate directly with you or is this the best method moving forward.

     

    Here are the problems we’re facing:

     

    We resolved the waiting for 'DONE' issue.

     

    We are able to load a simple application, based on sample in readme.txt, which utilizes

    the SK kernel. The app produces a customer key in the structure, and we are able to enable JTAG.

     

    We then tried running SecureHexAIS_OMAP-L138 with the ini configured as

    (NOTE keyEncryptionKey):

     

    [General]

    BootMode=UART

     

    [Security]

    securityType=GENERIC

    bootExitType=SECUREWITHSK

    encryptSections=ALL

    encryptionKey=4A7E1F56AE545D487C452388A65B0C05

     

    genericSHASelection=SHA1

    keyEncryptionKey=E817ABE9FF984FD74EE3553F0A143740

     

     

    We then tried running SecureHexAIS_OMAP-L138 with the ini configured as

    (NOTE genKeyHeaderFileName using the file generated above):

     

    [General]

    BootMode=UART

     

    [Security]

    securityType=GENERIC

    bootExitType=SECUREWITHSK

    encryptSections=ALL

    encryptionKey=4A7E1F56AE545D487C452388A65B0C05

     

    genericSHASelection=SHA1

    genKeyHeaderFileName=gen_keyhdr_encrypted.bin

     

    We then load binary file created by the last step using the same application as above.

    We then try booting, but the boot fails.

     

    Frank

  • 0 in reply to frank handal
    TI__Prodigy 490 points

    Frank,

      Thanks for the more detailed information. 

      One thing to note that when using the Secure Kernel as the exit type, you need to make sure to reserve the second 16 KB of L2 for the Secure Kernel.  The reason it is the second 16 KB is to make sure the Secure Kernel was aligned with all boot modes (NOR legacy mode and UHPI boot mode use parts of the first 16 KB).

      Also, the keyEncryptionKey field is only used for debug.  When you generate the header, you need to actually use the KEK within the device instead of one specified in the INI file.  Try to regenerate your header with that option removed and see if that fixes the issue.

    Thanks,

    Erik