• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: SecureHexAIS_OMAP-L138 utility and ARM images

Gert Cronje
Prodigy 40 points
Part Number: OMAP-L138

We are currently implementing the ARM9 side of our software based on the OMAP-L138. 

We are able to pack the U-boot and Linux kernel images along with the DSP image into FLASH using the SecureHexAIS_OMAP-L138 utility.

We do this by adding the files with the @<load address> parameter.

The DSP secure FLASH bootloader successfully loads the ARM9 images into the correct DDR addresses and when the DSP starts the ARM9 core it boots correctly.

However, when we also try to place the Linux ramdisk image into the FLASH, the DSP never completes the secure boot. We see brief activity on the FLASH address lines and then nothing. We are also not able to connect to the DSP via JTAG when it is in this state.

The ramdisk is quite small (4MB), and when we use a file containing random binary data of similar or larger size (I tried up to 6MB) it does boot correctly. So it seems as if something in the ramdisk file breaks the boot. The ramdisk is compressed with GZIP.

We suspect that the SecureHexAIS_OMAP-L138 generates a corrupt programming file.

Any insight into this issue would be appreciated.

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 114420 points
    Gert,

    Can you please describe the system boot to me. My understanding is that the secure boot on your device will download a secondary bootloader on the DSP and load the uboot into memory. The bootloader on the DSP will then bring the ARM out of reset and and start ARM execution from the entry point of uboot. the uboot then proceeds to boot the linux on the ARM.

    Can you indicate why the ramdisk is passed into the SecureHexAIS utiltiy, do you want that to be also loaded by the secure bootloader. when you create the ramdisk image is the image an exact multple of sector/page size of the boot media. My suspicion is that the AIS tool is providing size in multiples of a word and if you RAM disk image is not multiple of 4 bytes then it may be padding 00 in the computation. On the flash media however when you erase the flash all the bytes are set to 0xFF instead of 0x00 so the signature calculation may not be matchinng up. Is there a way you can pad the RAMdisk image so that its size is multiple of 4 bytes or the boot media page/sector size so the tool doesn`t need to pad 0x00 while computing the hash/signature.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 40 points

    Hi Rahul.

    Thanks for the reply.

    Our board has 256MB DDRAM. The DSP uses the first 128M and the upper 128M is for the ARM. Apart from the FLASH, there is no other storage in the system. Once booted, both processors will run from DDRAM.

    Our aim is to secure both the DSP and ARM code using the secure boot capabilities of the secure OMAP-L138.

    We want the DSP secure bootloader to load both the DSP code and ARM code into DDRAM. After the DSP has booted up, a user command is given to the DSP to start the ARM.

    The ARM bootloader (u-boot), Linux kernel and RAMdisk should already be placed at the correct locations in DDRAM when the DSP sets the start address (of u-boot 0xc9000000) for the ARM and takes it out of reset.

    This works mostly, apart from the fact that certain ramdisk (and I now discovered kernel images as well) breaks the secure boot - i.e. the DSP never starts executing.

    I'll investigate padding the images as you suggested. We also have the option of placing the ARM linux kernel and ramdisk in another bank of the FLASH which is not acessible to the secure bootloader and having the DSP copy it out later.

    Regards

    Gert

  • 0 in reply to Gert Cronje
    Prodigy 40 points
    Hi Rahul.

    OK, padding the files to a multiple of 4 bytes resolved the issue.

    Thanks for the help.

    Regards

    Gert