• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 887 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Booting from SPI flash on DM814x

Eric Chen
Intellectual 810 points


Hi,

    I'm trying to write my code to SPI flash then boot from the flash in Windows environment. Referring to TRM, I did the following steps:

1. Build my code *.out in CCS as image file. It's configured to use external memory because of the code size.

2. Add image size and destination address (0x80000000 in DRAM) to the head of this image. (Refer to "1.9.1.1 Image Format for GP Device" in SPRUGZ8.)

3. Use spi-flash-writer obtained from Linux PSP package to write image to flash with offset 0.

    I have verified data written to flash are what the code is. When I disconnected JTAG and power cycle the board, boot up failed. The core register stayed at 2008Ch which is the default handler of data abort. I have some questions on such method:

1. Does it need to transform the built code *.out to any format as an image? If necessary, how could I do that? It seems that there's an AISGen tool to generate the binary data for image. Is it available on DM814x?

2. Is it possible to assign the destination address of external memory and let ROM boot shadow the image to it instead of internal RAM?

3. Is the procedure sufficient to make the board able to boot up alone with my code? Any extra step needed to make this boot-up work?

 

Regards,

    Eric

  • 0
    TI__Intellectual 2615 points

    Hi Eric,

    The image flashed should be in big-endian format. Please try converting the whole image (including the header) into big-endian, flash it and then try SPI boot mode.

    We will check our team on the documentation regarding endian-swap for SPI boot mode.

    Regards

    Mansoor

  • 0 in reply to Mansoor Ahamed
    Intellectual 810 points

    Yeah, I've noticed that SPI sends MSB first, so the image was transformed as big endian format. Sorry I didn't mentioned it on my post.

  • 0 in reply to Eric Chen
    TI__Intellectual 2615 points

    Hi Eric,

    At this point the only option we have is to single step the code from reset. Please select "Halt on Reset" option for the A8 core in CCS and reset the system from "Reset" -> "System Reset". This should get you to the first ROM instruction after reset. You could single step from this point. Also, let us know the contents of LR register when the PC is in 0x2008c.

    One more option we could suggest is to coyy only the binary (without endina-swap) to the OCMC RAM and then set the PC to th first instruction in your binary (skipping the header). You should do this once PC is at 0x2008c (or immediately after a system reset without "halt on reset"). This should help you to debug your binary directly on the internal RAM without flashing it to SPI flash.

    Regards

    Mansoor

  • 0 in reply to Mansoor Ahamed
    Intellectual 810 points

    At this point the only option we have is to single step the code from reset. Please select "Halt on Reset" option for the A8 core in CCS and reset the system from "Reset" -> "System Reset". This should get you to the first ROM instruction after reset. You could single step from this point. Also, let us know the contents of LR register when the PC is in 0x2008c.

    I follow the steps. It looked fall into a endless loop from PC=0x2086C to PC=0x20874 in single steps, so I pressed F8 (resume) then pressed pause to reach where PC=0x2008C. The content of some core registers are as below:

    PC=0x0002008C

    SP=0x00000000

    LR=0x000221F2

    CPSR=0x00000197

     

     

    One more option we could suggest is to coyy only the binary (without endina-swap) to the OCMC RAM and then set the PC to th first instruction in your binary (skipping the header). You should do this once PC is at 0x2008c (or immediately after a system reset without "halt on reset"). This should help you to debug your binary directly on the internal RAM without flashing it to SPI flash.

    This method works, but it need some other interface (e.g. JTAG) to copy the image to memory. I hope I could write my code to flash and let ROMBoot load the code then execute.

    The following steps are what I did currently:

    1. Build .out file in CCS.

    2. Use the tool "hex470.exe" to transform this .out file to .bin. (The binary is little-endian format.)

    3. Load this binary to external memory in CCS. (Load memory in memory browser)

    4. Add size and destination address in the head of the memory (in little endian format).

    5. Dump the memory including header in "Byte" format to an endian-swapped binary file. (Save memory in memory browser)

    6. Execute spi-flash-writer in CCS to write the binary file in step 5 to spi flash.

    7. Power cycle the board.

    Then, boot failed.

    Step 3 to 5 is to make endian-swap because I have no such tool on hand.

     

    I also post questions about U-Boot and some one answered that U-Boot method in Linux PSP package is the only way to write image to flash and make the board able to boot up alone. It makes me confused.

    Regards,

        Eric

  • 0 in reply to Eric Chen
    TI__Expert 6175 points

    Eric,

    Which version of DM 814X are you using? Es1.0 or the newer ES2.0? Also, could you try flashing u-boot to the board and checking if it is booting properly? Converting a .out to a .bin is actually quite tricky - you need to properly adjust the memory map to take care of entry point and loading...

    To do s simler check, can you simply build a 4 byte .bin that only have a single infinite loop in asm and try to build, flash and boot that? That will help make sure that your flow is working, and give you a starting point to do your dev.

    By the way, it is always a good idea to leave  a spin lock at the entry point of your code while doing dev - it makes it easier to attach CCS and debug crashes.

    Regards,

    Madan

  • 0 in reply to Eric Chen
    TI__Prodigy 515 points

    Eric,

    I need an additional Input from you. Can you please tell me what is the Bootmode pin value you are configuring and the value of Control Status register (0x48140040)

    Regards,

    Gaurav

  • 0 in reply to Madans
    Intellectual 810 points

    Sorry for my slow reply.

    I think some configuration code for peripheral is not correct and cause it can't execute well.

    I changed to use the u-boot from linux psp 4.01.00.05 package on EVM board. Everything was OK and I can see prompt of 2nd stage u-boot on my host console.

    The DDR2 memory and flash chip are different between EVM board and our developing board. I'm going to use the 1st stage u-boot.min as base and modify the code for our board. The source of u-boot looks complex. Is there any clue for which files I should modify for different DDR2 and flash chips?

    Thanks in advanced.

        Eric

  • 0 in reply to Eric Chen
    TI__Intellectual 2615 points
    Hi Eric, It would be helpful if you could close this thread and start a new thread for DDR configuration. This would help our engineers to track it and respond faster. Regards Mansoor
  • 0 in reply to Mansoor Ahamed
    Prodigy 25 points
    Hi Eric, I had the same problem and could solve it without U-BOOT. Unfortunately, this forum doesn't like my spaces and new-lines. You will find a detailed description in the attached .doc-file. Greetings Thomas
    DM8148_bootloader.doc
  • 0 in reply to Thomas Starke
    Intellectual 810 points

    Hi Thomas,

        Thank for your information. I think we did the same way to boot from SPI flash, except that I modified 1st stage u-boot mini to configure necessary peripherials and replace 2nd stage u-boot by our customer code which is loaded to external memory (due to large code size). This works as well. 

     

    Regards,

        Eric