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.

SECDEVTOOL-OMAPL138C6748: OMAPL138E won't boot after binding process

Part Number: SECDEVTOOL-OMAPL138C6748


TI Experts,

I'm having trouble successfully binding the test program from the security collateral folder for the OMAPL138E.

I'm able to boot the OMAP with the test program that prints to UART forever by flashing its AIS image to SPI. I'm also able to run the secureboot binding code on the device and verify that the code executed to the end without printing any error statements to UART, but when I try to boot the OMAP after the binding process it doesn't boot anything.

The test program exits in nonsecure mode and has the JTAG ports open. Before the binding process I can connect to the DSP through JTAG and see that my test program is running normally as expected. After the binding process I'm unable to connect to the DSP through JTAG as it seems that the DSP never exited the secure ROM bootloader.

Has there been any updates to the security collateral folder since Jan 1st, 2020?

I'm using CCS version 10 using cgt c6000 version 7.4.24

Any help is appreciated,

Thanks

  • There has been no update to secure collateral since Jan1st 2020. This is a fairly mature device so the the secure collateral is in maintain mode and there is no active development around this feature. 

    We do have a couple of SPI and NAND boot examples that show the process of binding. Please indicate if we have not previously shared this with you.but those examples show the exact sequence involved in signing and encrypting the header for the image.

    Regards,

    Rahul

  • Hi Rahul,

    I have received the secureboot collateral code for SPI and NAND booting earlier from you this year. If there are any more examples besides the ones mentioned please send them to me as it could help debug my issue.

    Do you have any recommendations for debugging this issue? I have followed every part of the document and still don't have any luck when booting after the binding process.

    What version of the StarterWare library is safe to use when recompiling the library objects that the project references? Also, why does the readme document in the folder state that,

    "DEBUG: SECURE BOOT FINISH!!!" means encryption is successful, but it's not included anywhere in the source code? Is there a part of code that checks if the bind was successful that wasn't included?

    Thanks

  • Starterware library version probably doesn`t impact this issue  The issue is probably related to the header format and the computed signature Your debug options are quite limited when the device fails to boot due to signature check failure as you can connect via JTAG And there will be no messaging through the UART. I would try to regenerate the header and the signature and make sure you write it back into flash in the correct order as expected by the ROM.

  • Rahul,

    > I would try to regenerate the header and the signature and make sure you write it back into flash in the correct order as expected by the ROM.

    I'm assuming the provided binding code already does this in the correct order. I haven't changed the source code or the ini files that are provided in the folder. Is there anything else that could go wrong in the binding process?

  • Are you using SPI or NAND flash ?

  • I am using SPI flash

  • To verify the functionality of using the SPI library when exiting in SK mode I commented out the part of the code that binds the header to the device so that all program does is read the image from SPI, erase the image, and then write the image back to address 0 of SPI.

    This test worked with multiple modules I have on hand. It seems that the only thing that is giving me trouble is using the binding code. I have also verified that the binding code, the test ini file, and secureboot ini file all have the same hashing algorithm selected with the same CEK specified.

    Are you able to try this process on your end by any chance?

    Regards

  • Looks like the code and configuration given from the zip file was setup slightly incorrect. Figured it out.

  • What was the incorrect issue? Could you share so others who may run into this problem have a solution? I am trying to figure out secure boot on the C6748, just waiting to get the collateral folder for binding examples.

    Thanks!