Debugging Secure TMS320C6748 device

Manjula Ellepola

Other Parts Discussed in Thread: OMAPL138, OMAP-L138, TMS320C6748

Hi Titus

We have got the boards at last with the secure version of the above device. However I am unable to debug it as the JTAG port is locked down. I have read snippets from the user manual etc saying that the secure versions can be debugged by booting the device into non secure mode and enabling the JTAG port.

Can you please point me to wikis/docs/examples on how to do this?

Thank you in advance for your valuable help.

Best regards

Manjula

over 9 years ago

0 Titusrathinaraj Stalin over 9 years ago

TI__Guru** 116100 points

Dear Manjula,

Yes, you are right. You have to disable the JTAG port on processor by exit "non-sec" mode for debugging the secured OMAPL138/C6748 SoCs.
You need *.ini file for converting *.out to secured AIS signed binary by secure AISgen tool (SecureHexAIS_OMAP-L138.exe).
You have to add the following lines in *.ini file.
[TAPSCONFIG]
TAPSCFG = 0x0000FFFF

After conversion, try to load that binary through secure UART host boot tool (GenericSecureUartHost.exe).

Please refer to the following TI wiki page.
processors.wiki.ti.com/.../Basic_Secure_Boot_for_OMAP-L138_C6748

0 Manjula Ellepola over 9 years ago in reply to Titusrathinaraj Stalin

Expert 1335 points

Hi Titus

Thank you for the reply. On our custom board we don't have the facility to boot via UART. In hindsight we should have added this.
Our intention was to boot the TMS320C6748 secure device from an SPI master. That is the secure DSP will be in SPI slave boot mode.
Today we tried this and it failed.
I saw a post saying that the secure version of this chip cannot be booted in SPI slave mode. Can you please verify this?
Nowhere in the documentation does it say that the secure version cannot be booted in SPI slave mode :(

Thanks for your help and BR
Manjula

0 Manjula Ellepola over 9 years ago in reply to Manjula Ellepola

Expert 1335 points

Hi Titus

Can you please provide an answer to the above asap please? We are about to send the boards back for rework to change the secure chips and this costs time and money. We need to be sure before we send back.

The question again is: "Can the secure version of TMS320C6748 be booted as a SPI slave from a master SPI device?"

I cannot find any documentation saying that this cannot be done. However I came across a previous post replied by you saying that the secure DSP cannot be booted by a master SPI device. Can you confirm this? See link below.

Thanks and rgds

Manjula

e2e.ti.com/.../1537527

0 Titusrathinaraj Stalin over 9 years ago in reply to Manjula Ellepola

TI__Guru** 116100 points

Dear Manjula,
Yes, you are right.
We don't support SPI slave boot in secure OMAPL138/C6748 processors.

0 Manjula Ellepola over 9 years ago in reply to Titusrathinaraj Stalin

Expert 1335 points

Hi Titus

This is disappointing. NO where in the documentation does it say that this mode cannot be used :(( TI really needs to get the documentation up to date. We have spent a lot of time and money doing these boards and now need to revise them at further cost and delay to the project.
I was really lucky to come across that post where the engineer had spotted this one line in a wiki page, otherwise we would have wasted more engineering time.

Thanks for your support Titus...we survive because of you.
BR
Manjula

0 Titusrathinaraj Stalin over 9 years ago in reply to Manjula Ellepola

TI__Guru** 116100 points

Dear Manjula,
Sorry for the inconvenience.
Yes, we are trying to update the wikis and user guides when ever we get the inputs from customers.
Sure, we will update the wiki page now. I will also try to not happen this again.

Also please don't hesitate to ask us that what is supported and what is not supported when you start the design.

Thanks for your understanding.

0 Manjula Ellepola over 9 years ago in reply to Titusrathinaraj Stalin

Expert 1335 points

Hi Titus

When we do a design there are at least a few thousand design parameters to consider. So it is not practical to pass all these by you guys to find out what is supported or not and a processor like the TMS320C6748 is very complex with at least 5000 pages of documentation :(

So what to do? You guys really need to get your documentation up to scratch. I have been repeatedly saying this as are a lot of engineers on this forum...please do something. The DSP is excellent...just need better documentation. We are also using an ARM processor from another vendor on this board and it is a dream to develop on their IDE and integrated support compared with TI and to boot the tools are free (Freescale).

Thanks for your support

BR

Manjula

0 Titusrathinaraj Stalin over 9 years ago in reply to Manjula Ellepola

TI__Guru** 116100 points

I agree Manjula.
We will update the wiki with required information soon.
Thanks for your input.

0 Titusrathinaraj Stalin over 9 years ago in reply to Manjula Ellepola

TI__Guru** 116100 points

Dear Manjula,
I requested secure DSP expert to answer that why the SPI slave is boot is not possible in secure C6748/OMAPL138 processor.

0 Rahul Prabhu over 9 years ago in reply to Titusrathinaraj Stalin

TI__Guru** 116170 points

Hi Manjula,

In the basic secure parts, the device boots using the KEK key on the device and the CEK key provided in your secure boot image. The KEK key can be read only in secure supervisor state when you run a piece of secure code on the device and can`t be exported out of the device. When you create an image using secureHexAIS tool, you get an image with a unencrypted header appended to an encrypted boot image which you can boot in SPI slave mode however this doesn`t provide full proof security as the software header is not yet encrypted using the device specific KEK. Hence we don`t recommend using SPI slave mode.

In master modes, the device on first boot reads the unencrypted header from the flash boot media encrypt it using KEK and writes the image back to the flash device. Since the boot master can`t write back on the SPI slave interface this scheme can`t be encrypted with a SPI slave device. Also even if you were able to implement this scheme, the other issue is that since the KEK is different on all devices, you would need a unique boot image to be loaded on each of the secure C6748 parts which makes it tedious.

I hope, we have been able to explain to you the challenges of using slave boot on secure parts.

Regards,
Rahul

0 Manjula Ellepola over 9 years ago in reply to Rahul Prabhu

Expert 1335 points

Hi Rahul,

Thank you for looking into this. So does this mean that SPI slave boot is completely disabled - no we cannot do it at all and the DSP will not respond at all or yes we can do SPI slave (DSP is slave) boot but not recommended?

From what I read, the boot image for every device is unique. That is the whole image is encrypted with the KEK and CEK combination which is unique and tied to the particular device. First we provide an UN-encrypted CEK via the header which is then encrypted by the KEK internally and provided to us. This encrypted CEK is then used to encrypt the image using the secure HEX ais tool. We burn this hexAIS converted image into SPI Flasn and this image is then bootable in the secure device. This is my basic understanding.That is it is a two step process.

I cannot find your following quote made by you in any documentation:

"In master modes, the device on first boot reads the unencrypted header from the flash boot media encrypt it using KEK and writes the image back to the flash device"

Do you mean that the DSP in master SPI boot mode, when booting reads the unencrypted header then encrypts the CEK and the image and actually writes back the encrypted image and encrypted header back to the flash device? That means the program to do this is provided in the boot ROM of the device and happens automatically depending on the boot mode chosen?

In a nutshell what you are saying is that all we have to do is provide a CEK and the image converted with the secureHexAis tool flashed on a SPI flash memory device and the secure DSP in master SPI boot mode will take care of the rest i.e. encrypt both the CEK and the image and write back to SPI flash memory (awesome)?

This is totally different to my understanding above and I haven't found this in any documentation.

Please clarify asap.

Thank you for your help

Best regards

Manjula

0 Manjula Ellepola over 9 years ago in reply to Manjula Ellepola

Expert 1335 points

Hi Rahul

I am awaiting answers to my questions in the previous post. Please be kind enough to clarify. It is difficult for us to deal with the missing information in the first instance, it is worse when our queries are not answered as we cannot fill the gaps in information and makes designing with these parts more difficult. A product is only good as it's support.

Thanks
Manjula

0 Rahul Prabhu over 9 years ago in reply to Manjula Ellepola

TI__Guru** 116170 points

Sorry for the delayed response on this issue. SPI slave boot is not disabled but is not recommended due to the challenges of implementing this on a basic secure part. As each device has a unique key burnt in them, you will need to create a unique image for each of the devices and keep track of them when you load them from the host.

The binding program to read the unencrypted software header from flash , encrypting it using KEK and then the write back to flash device is not done by the BootROM. Developers are required to boot the binding application over UART that will bind the boot image in the flash with the unencrypted software header by encrypting it using KEK. We provide sample code to bind images in SPI flash and NAND flash, that we can share with you if you would like.

The BAsics secure boot on OMAPL138/C6748 refers to this process. Also chapter 7 of the security user guide provides pseudo code that descibes the process of encrypting the unencryopted header with the KEK.
processors.wiki.ti.com/.../Basic_Secure_Boot_for_OMAP-L138_C6748

Regards,
Rahul

Processors

Processors forum

Debugging Secure TMS320C6748 device