• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Digital Signal Processors (DSP) » C5000 Ultra Low Power DSP » C5000 Ultra Low Power DSP Forum » Secure Boot Image from NOR Flash and SD Cards
Share
C5000 Ultra Low Power DSP
  • Forum
  • Announcements
Options
  • Subscribe via RSS
Top 6 Wiki Links
  • C5000 Main Wiki
  • C5000 Software
  • C5515 Boot-Image Programmer
  • CSL (including CSL 3.00)
  • C5000 Connected Audio Framework
  • Porting C5000 Teaching ROM to C5535 eZdsp
  • Secure Boot Image from NOR Flash and SD Cards

    Secure Boot Image from NOR Flash and SD Cards

    This question is answered
    dpryan
    Posted by dpryan
    on Apr 16 2012 15:44 PM
    Intellectual280 points

    I'm having trouble booting from a SD card on the C5505. I've obtained the C55BootImageV2.exe program and associated documentation, and I have had some success getting it to work on the ezDSP C5515 board in NOR flash. On the evaluation board, I was able to boot both encrypted and unencrypted from NOR flash. When encrypting, I was able to use various keys (all 0’s, 10…01, all 0xA’s, etc.) and it still booted.
    (It’s not possible to boot from SD on that evaluation board since the SD card is on the MMC/SD1 port instead of SD0, but NOR flash booting worked.)

    We wanted to replicate this on our custom C5505 board, and then also extend our success to boot from the microSD card (which is on MMC/SD0).

    On our C5505 board, we can boot from NOR flash using the following command to generate the bin file:
    "C:\Tools\TI\ccsv5\tools\compiler\c5500\bin\hex55.exe" -boot -v5505 -b -fill ffh program.out -o program.bin

    However, when we use the C55BootImageV2 to create an unencrypted (or encrypted) image and put it in NOR flash, our processor fails to boot.
    (We then reverified that we could still boot from our hex55 generated bin.)

    What’s different in these scenarios? It seems like the only difference is the flags passed to hex55.exe. I don’t think there is any way to specify additional flags to the C55BootImageV2.exe.

    What's going wrong?

    Additional info: We're not using SARAM31:
    SARAM31 (RX): origin = 0x04E000, length = 0x002000 
     /*  SARAM31 reserved for Boot Loader */

    C55X C5505 Bootloader C5505 VC5505 C5515 Bootloader
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • dpryan
      Posted by dpryan
      on Apr 16 2012 18:20 PM
      Intellectual280 points

      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.”

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • dpryan
      Posted by dpryan
      on Apr 17 2012 12:04 PM
      Intellectual280 points

      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

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Mark Mckeown
      Posted by Mark Mckeown
      on Apr 17 2012 18:10 PM
      Genius10210 points

      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
       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
      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

      ---------------------------------------------------------------------------------------------------------
      Please click the Verify Answer button on this post if it answers your question.

      Also see our C5000 Wiki
      ---------------------------------------------------------------------------------------------------------

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • dpryan
      Posted by dpryan
      on Apr 17 2012 18:57 PM
      Intellectual280 points

      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.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • dpryan
      Posted by dpryan
      on Apr 17 2012 19:28 PM
      Intellectual280 points

      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

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • dpryan
      Posted by dpryan
      on Apr 17 2012 20:32 PM
      Intellectual280 points

      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.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Jrvanho
      Posted by Jrvanho
      on Apr 19 2012 09:29 AM
      Intellectual730 points

      Mark,

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

      Cheers

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • dpryan
      Posted by dpryan
      on Apr 23 2012 10:24 AM
      Verified Answer
      Verified by dpryan
      Intellectual280 points

      This problem was solved by Jrvanho. I'm posting the resolution here in case other people run into the same issue.

      I am now able to boot the [large] application encrypted from the SD card.
       
      The encryption tool does not handle the RAM linker command properly (-cr) for encrypted and non-encrypted binary files.  This can be bad if you start putting bss sections off-chip because of the boot loader silicon bug. But since most of your software is back on chip I was able to get it working.
       
      After playing around in the boot loader, it looks like we were getting a stack over flow when booting from the SD card.   Since the application is now pretty “large”, it looks like the boot loader’s stack continues to grow up in SARAM block 30. So as soon as I prevented code/etc from being placed in that section  it was able to boot.
       
      Cheers,
      Jrvanho
      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Jrvanho
      Posted by Jrvanho
      on Apr 24 2012 09:48 AM
      Intellectual730 points

      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?

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    TI E2E™ Community
    • Support Forums
    • Blogs
    • Videos
    • Groups
    • Site Support & Feedback
    • Settings
    TI E2E™ Community Groups
    • TI University Program
    • Make the Switch
    • Microcontroller Projects
    • Motor Drive & Control
    Other Communities
    • Deyisupport
    • Designsomething.org
    • beagleboard.org
    • TI on Element 14
    • TI on TechXchangeSM
    Other Technical & Support Resources
    • WEBENCH® Design Center
    • Product Information Centers
    • Technical Documents
    • TI Design Network
    • TI Technical Articles
    • TI Training

    All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

    Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

    Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
    TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

    TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
    embedded processors, along with software, tools and the industry’s largest sales/support staff.

    © Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
    Trademarks | Privacy Policy | Terms of Use