Secure Boot Image from NOR Flash and SD Cards

Also, can you verify that this wiki is wrong? (As of Last Modified date: 26 January 2012)
All the other documentation says that you cannot boot using a non-encrypted boot image using a SD card, but the above wiki doesn't even mention secure boot images.

Most resources say something like the following:
“In order to ensure the code cannot be accessed and read outside of the system, only encrypted images can be boot from MMC/SD and USB. Both encrypted and non-encrypted images can boot from NAND, NOR, 16-bit SPI EEPROM, and I2C EEPROM.”

So, I bluewired the C5515 EZDSP board so the lines of MMC/SD0 are connected to MMC/SD1 (by soldering wires to the edge connector). I also unpopulated R74,75,76,77 to disconnect the I2S device.

I can now see the SD clock toggle on the microSD card, but the boot5505.bin image does not boot.

Does the bootloader properly pin-mux the SD1 port (to high-Z GPIO)? If not, that might interfere with the booting since some of the SD/MMC lines might be driven by multiple lines of the C55x (since the MMC/SD0 and MMC/SD1 lines are shorted together pairwise by bluewires).

If the MMC/SD1 pins are properly muxed to Hi-Z GPIO by the ROM bootloader, then I don't know what's wrong.

I'm assuming my boot5505.bin image is correct since the following is true:
1) It is encrypted but not "Bound to Device"
2) It works in NOR Flash

Hello,

Sorry for your trouble. Lets figure out what is going on...

I understand that your C5515 eZdsp...
        NOR Boot
            unsecure boot works
                hex55 worked - CONFIRMED
                C55BootImageV2.exe worked (unsecure) - CONFIRMED
            secure boot works (C55BootImageV2) - CONFIRMED            

I understand that your custom C5505 board...
        NOR Boot
            HEX55
                unsecure boot works
            C55BootImage
                unsecure boot FAILS
                secure boot FAILS
        SD Boot
            Have you tried booting from SD?

Additionally, I have tested the C5515 EVM for boot...

    C5515 EVM
        NOR
            HEX55
                unsecure boot PASSES - hex55
            C55BootImageV2
                unsecure boot PASSES
                secure boot PASSES
        SD
            C55BootImageV2
                unsecure boot FAILS (EXPECTED)
                secure boot PASSES

Can you use the C5515 EVM as your development board?

Check for valid Boot Signatures in each .bin file with a Hex Editor?
    First 16-bits of .bin file
        Unsecure: 0x09AA
        Secure: 0x09A4, 0x09A5, 0x09A6

Can you tell me the exact part number of C5505 on custom board?

Have you formatted SD card with FAT16/32?

Are all boot sources with higher precedence erased? (NOR erased when booting from SD) - Clear first two bytes (boot signature)

dpryan said:

 Also, can you verify that this wiki is wrong? (As of Last Modified date: 26 January 2012)
All the other documentation says that you cannot boot using a non-encrypted boot image using a SD card, but the above wiki doesn't even mention secure boot images. 

The C5535 DSP family can boot non-secure .bin files over SD - I will clarify that wiki to say so. It is the only device of the C5505/C5515/C5535 devices to support non-secure boot from SD.

dpryan said:

So, I bluewired the C5515 EZDSP board so the lines of MMC/SD0 are connected to MMC/SD1... Does the bootloader properly pin-mux the SD1 port (to high-Z GPIO)?

No, during the boot from SD phase of the bootloader, both serial ports are pin-muxed for the SD interface... Serial Port 0 for SD0 and Serial Port 1 for SD1. So I could expect possible contention in the case where both SD interfaces are shorted together. You might try to cut the PCB traces from microSD card slot to SD0 to remove the shorting - THIS WILL VOID YOUR BOARD'S WARRANTY

I have also attached some test .out and .bin files. This program simply toggles LEDs (check the XF LED). Try these files with your board and let us know the results. If these bin files boot correctly, then there may be something strange with your program...

I dont understand how unsecure .bin files can boot from the NOR flash on your custom C5505 board, but the secure .bin files cannot...

What NOR flash are you using? What chip select is it connected to?

Hope this helps,
Mark

7510.led_boot_tests.zip

Hi Mark,

Thanks for your detailed response.

eZDSP C5515 Module
Presumably everything is working fine with the eZDSP C5515 module with the EZDSP_Sample project. As you mentioned, I can boot from NOR encrypted and unencrypted. In a couple days, I'll be able try booting from SD by grabbing a new eZDSP module and attaching an external microSD to the SD0 port (and again unpopulating R74,75,76,77 of the I2S device). This will avoid the contention caused by attaching SD0 and SD1 together. I think it is very likely that it will work.
(Bin file generated by C55BootImageV2 was 27,014 bytes for the EZDSP_Sample project.)

Custom C5505 Board
The C5505 chip is TMS320C5505AZCHA12.
The NOR flash chip is Spansion S29GL064N11FFIV10 connected to CS2. (4MBytes x 2 Banks (via GPIO control))

Our C5505 board is connected quite differently compared to the eZDSP module, so rather than use the same EZDSP_Sample project (which would produce no visible output... no easy way to see if it is working), I initially tried our much more complex application project running DSP/BIOS. (Bin file generated by C55BootImageV2 is 219,064 bytes). This was the project that worked out of NOR flash when using the hex55 tool, but not the C55BootImage tool. It also didn't work out of microSD.

After some more experimenting today, I was able to get a different project to boot from microSD on our custom 5505 board and generate some output using our external CS5 UART validating that it worked (booted from microSD). That bin file generated by C55BootImageV2 was 136,414 bytes for this project. I didn't try on NOR flash, but presumably it works there, too.

Since this worked, you can guess the answers to most of your questions: (Formatted with FAT32, higher boot sources were erased, boot signatures were 0x09A5)

So, it seems to core of the issue that I'm having now is why boot images generated by the hex55 tool work while the C55BootImage doesn't work for certain projects. Maybe it has to do with the project size or the way code is placed?

As you put it:
            HEX55
                unsecure boot works
            C55BootImage
                unsecure boot FAILS
I think if we can figure out how to fix that problem, I'm pretty sure the secure images will boot from microSD.

Thanks again for your help.

P.S. I'll let you know the results with your sample project once I try it out.
Also, I have a C5505 EVM (not C5515) that I could try if needed.

I just took a closer look at the map file for our DSP/BIOS project.

I forgot to mention earlier  that external CS3 SRAM (CY62167EV18LL-55BVXI) is being used by our DSP/BIOS project on our custom board.
However, I don't think that should cause a difference between the hex55 tool and the C55BootImage tool.

SARAM is split to avoid 64kword boundaries. (Although we use huge memory model, so it shouldn't really matter.)

         name            origin    length      used     unused   attr    fill
                        (bytes)   (bytes)    (bytes)   (bytes)
----------------------  --------  ---------  --------  --------  ----  --------
  VECT                  00000100   00000100  00000100  00000000  RWIX
  DARAM                 00000200   0000fe00  0000fdf0  00000010  RWIX
  SARAM_1               00010000   00010000  0000ffcd  00000033  RWIX
  SARAM_2               00020000   00020000  0001fff5  0000000b  RWIX
  SARAM_3               00040000   0000e000  0000e000  00000000  RWIX
  SARAM31               0004e000   00002000  00000000  00002000  RWIX
  EMIF_CS3              00c00000   00200000  001028ea  000fd716  RWIX

Using your programs:
The run time of the program (and the speed at which the leds toggled) varied according to the boot method.
It ran quickly out of RAM, but slowly when booting from flash. I would have thought the execution time would be approximately the same since the bootloader copies from NOR flash to RAM before executing the program.

Quick = Run time ~3 seconds
Slow = Run time ~25 seconds

eZDSP Module:
RAM:
    Worked. led.out (Quick ~3 second run).
NOR:
    Worked. led_C55BootImage_secure.bin (Slow).
    Worked. led_C55BootImage_unsecure.bin (Slow).
    Worked. led_hex55_my_flags.bin (Slow).
    Worked. led_hex55_your_flags.bin (Slow).
microSD:
    (Will be tested on Thursday)

Custom C5505:
RAM:
    Worked. led.out (Quick ~3 second run).
NOR:
    Worked. boot5505.bin (aka led_C55BootImage_secure.bin) (Slow)
microSD:
    Worked. boot5505.bin (aka led_C55BootImage_secure.bin) (Slow)

Edit: I didn't think the secure boot image worked on the C55x custom board when I tested yesterday, but I just tried it again today and it seemed to work out of NOR and microSD. (I verified that it boots with microSD but doesn't boot with the microSD card ejected, which sorta proves that the NOR flash was cleared for this microSD test.)

Edit2: The difference between fast and slow is probably my gel script that gets run before running the .out files in ram.

Mark,

Has anyone tested booting a secure boot image that was linked using the RAM autoinitialization model instead of the ROM?

Cheers

Can someone from TI verify that the RAM linker command doesn't work properly?  If so, is it possible to get this fixed because of the silicon bug?