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.

SecureBoot chip doesn’t encrypt user key

Other Parts Discussed in Thread: OMAP-L138, OMAP-L137

3056.none_busWidth.ini

1157.SPIMASTER_AddrWidth.ini

Hello,

We are testing the SecureBoot feature with our SPI1 flash. The chip select pin is SPI1_SCS0 as required by SPRAB41E.

A total of four files have been generated with the following commands:

  1. SecureHexAIS_OMAP-L138  -ini "none_busWidth.ini" -otype binary -o "aNone.bin" "ARM_testBoot.out"
  2. SecureHexAIS_OMAP-L138  -ini "SPIMASTER_AddrWidth.ini" -otype binary -o "aSPI.bin" "ARM_testBoot.out"
  3. SecureHexAIS_OMAP-L138  -ini "none_busWidth.ini" -otype binary -o "dNone.bin" "DSP_testBoot.out"
  4. SecureHexAIS_OMAP-L138  -ini "SPIMASTER_AddrWidth.ini" -otype binary -o "dSPI.bin" "DSP_testBoot.out"

So there are actually one DSP .out file and one ARM .out file with exactly the same code: toggling a multitude of GPIO pins with while(delay), even without using timer. The pins being toggled are

GPIO {0_1,0_2,0_5,0_15,1_9,1_11,1_13,5_6,5_12,6_2,6_3,6_14,7_0,7_2,7_3,7_4,7_5,7_6,7_7,7_9,7_10,7_11,7_12,7_13,7_14,7_15,8_2,8_6,8_8,8_9,8_10,8_11,8_13}

All ARM content is allocated and linked into 128KB shared RAM (start at 0x80000000), and all DSP content is linked to L2 (start at 0x11800000) so their running doesn’t require DDR setting. At 300MHz the ARM toggles GPIO pins at about 800Hz, and DSP toggles them at about 6000Hz.

After we burn the flash and attach them to sockets on to ZWTA3E (secure version) boards, none booted successfully. Oscilloscope detects a brief period of SPI_CLK pulses (about a dozen μs) upon power on the CLK pin of the flash, but then stops permanently. Then we remove them from secure boards and examine the flash content, we found the image was not altered at all, which means the structure of the Key Data was not encrypted by KEK in the eFuse.

The “SecureHexAIS_OMAP-L138” was not altered/recompiled, and is the same as downloaded from TI.

Regarding Secure Kernel API, none were included in the code of the GPIO toggling applications.

We also verified the four files all begin with 41504954h 58535920h BE40C0DEh. In addition, the secure board itself is perfect fine with BOOTMODE pins wired for SPI1 flash booting, and have successfully booted many images generated by non-secure AIS_GEN on non-secure L138 processors.

We are very frustrated as we have been testing with SecureBoot for days, and have re-made board with removable Flash sockets with quite some investment, but the experiments doesn’t go through.

The content of the two .ini files are here attached, and we are also sending .out and .bin files privately, soliciting TI expert’s help.

 

 

Jeff

  • Sure Jeff,

    We will look into it and get back to you at the earliest.

    Regards,

    Shankari

  • Dear Shankari,

    Thanks very much for prompt help. Could you accept my friendship request so that I can send my email address to you?

     

    Jeff

  • Dear Shankari,

    If a corrected version of the .ini file and the correspondingly generated .bin file can be sent to me via forum message, I would deeply appreciate that. This is the quickest way I could learn to make the booting work.

     

    Jeff

  • Hi,

    Any update?

    This request is urgent as we are moving towards production, please help!

    Jeff

  • Hi Jeff,

    Your post was already brought into Expert's notice. But he is on someother high priority task and you may expect some reply only after couple of days!.

    I apologize; I am personally not very much familiar with secure devices but only with non-secure boot and moreover, I do not have any hardwares with secure devices in hand, right now, to have a detailed look.

    Please bare with us until the expert reply.

    And I hope, you already looked into this TI WIKI : http://processors.wiki.ti.com/index.php/Basic_Secure_Boot_for_OMAP-L138_C6748

     

    Regards,

    Shankari

  • There has been another 3 days. May I ask if the expert is still busy with his current assignment?

    Jeff

  • Two points and a few suggestions:

    1st point: The secure devices have the DSP as the security master, so you can't boot an ARM image. The best migration path from a working non-secure system to a secure system is to go from a non-secure C6748 device to a secure OMAP-L138 device. If you have a simple GPIO test case that boots and executes on the C6748 DSP, then adding the security features and getting it to boot on the OMAP-L138 should be fairly trivial.

    2nd point: For booting from SPI flash, you need the AddrWidth variable set correctly. The value of 8 is almost certainly incorrect. Likely the correct value is 24 (for flashes up to 16MB), but you need to check your datasheet. This value shouldn't change going from a non-secure part to a secure part, so consult the INI file you used for booting on non-secure parts.

    Suggestion: Disable the encryption option (comment the encryptSections line) and disable the EMIF3DDR section to make the boot image as simple as possible.

  • Daniel.

    Sorry for replying late. I indeed have tried 1) using only DSP boot 2) AddrWidth to 24; 3) "encryptSections" and "EMIF3DDR" are commented.

    However the result was similar: after POR reset the CLK pins briefly shows a train of clocks for some 20,000 periods, each period some 8 clocks, whose total length convince us that the entire image has been read into the chip (load address = 0x11800000, DSP's L2 memory).

    However, we still cannot see the GPIO pins toggling even there are dozens of pins programmed and successfully toggled on non-secure devices.

    I have sent the testing code and SecureHexAIS_OMAP-L138 .ini and .bin files to you. Could you check if they can boot on your EVM?

     

    Jeff

  • Hello,

    May I have an update on this?

     

    Jeff

  • Jeff,

    Your INI file shows that the JTAG taps are being unlocked during boot. Can you connect to the processor via JTAG after boot has completed?

    Regards, Daniel

  • Daniel,

    Yes. I am debugging the issue now.

  • If you can connect to the part via JTAG, then the boot process was successful. So you are not debugging an issue with the boot image, but rather an issue with the program execution. It could be that you need to open up the IOPUs, and without them open the GPIO operations don't complete.

    Regards, Daniel

  • Indeed after accessing JTAG it was found that the GPIO PSC was not enabled.

  • Daniel,

    Could you send me some more documents (user guide, example) for the secure kernel API?

    SPRUGQ9, the 2011 version guide, the SK API contents spanned 10 pages with 5 code snippets. However merely with these short snippets I found difficulty in understanding the working of the API. Rahul have mentioned in a 2012 post that there was updated beta version of the secure device development package which so far seems not yet released. May I request for a copy of that?

     

    Jeff

  • Daniel,

    For non-secure device the booting is with ARM and after booting DSP is held in reset which requires ARM to

    1) program HOST1CFG.DSP_ISTP_RST_VAL

    2) enable DSP PSC

    which is discussed in 13.2 DSP Wake Up of SPRUH77.

     

    For secure device after DSP is booted and JTAG access allowed, I found ARM is disabled and connection impossible with CCS prompting that ARM is in reset. Therefore analogously does it require DSP to enable ARM by enable it in PSC first?

    However, there is no corresponding booting address vector as HOST1CFG.DSP_ISTP_RST_VAL for DSP. How is the ARM booting address determined?

     

    Jeff

  • The ARM reset vector is fixed and is not programmable. You have inadvertently stumbled across a somewhat difficult process. See this wiki link:

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L137#Booting_ARM_Binaries

    Basically, you need to get some code into the ARM instruction RAM, but you don't have direct access to do that from the DSP. The solution is to use another entitty which does have that capability, in this case the PRU. Though the article is titled as being for the OMAP-L137, the information presented is directly applicable to secure OMAP-L138 parts, which is also a DSP-boot part.

    Regards, Daniel

  • Jeff Johanson said:

    Could you send me some more documents (user guide, example) for the secure kernel API?

    I do not have any further documentation than what is publicly released and I don't have any knowledge of new documentation that was in the works. I will try to see if the team responsible for this device can address this question.

    Regards, Daniel

  • Hi Jeff,

    I have provided source files with the secure Kernal API files and an example of secure boot over SPI boot mode in a private conversation. Please review the examples and let us know if you have any further questions.

    Regards,

    Rahul

  • Daniel,

    Thanks, I am looking at the wiki article now.