• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 669 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.

SD boot configuration

and
Prodigy 205 points
Other Parts Discussed in Thread: OMAP3503

Here is my problem summary:

 

I’m trying to use the “Software Boot Configuration” defined in 25.4.4.4 in the TRM,  to transfer the ROM boot from using the strapped sys.boot (to a NAND flash) to boot to an SD card (on MMC1) after a software reset.  What I am finding is that:

  1. After the software reset the ROM bootloader is not executing with a cold reset.
  2. The ROM bootloader is not finding my Software Boot Configuration previously configured in the internal memory.

 

Here is my background information.

 

The issue is we have an OMAP3503 on a board that has both a NAND flash and an MMC/SD card (connected to MMC1).  The sys.boot pins are strapped to boot from NAND flash. This client has had issues with reliability on the NAND flash. Even after we supported them with ECC on the flash and periodic scrubbing of the NAND flash they are still seeing too many field failures.

 

Originally the x-loader, U-boot and Linux kernel was stored in NAND  ( There was also a boot strap kernel and root file system in the NAND flash). The primary root file system was on the SD card to facilitate upgrades.

 

They have asked us to change the bootloader to minimize the amount of code/data in NAND flash.  My approach was move all of the data/images to the SD card except what I term a NAND boot redirect program that will still be in NAND flash.

 

I have first had a board moded to allow me to select the sys.boot setting through a set of switches.  I have verified that when the sys.boot is set for a  SD boot (with my formatted SD card) it will boot an x-loader successfully.

 

My issue is in the NAND redirect program.

 

I created a stripped down program of an x-loader. It still performs the nominal x-loader config as before,  however afterwards in the start_armboot() function  (board.c attached)  I take a reserved copy of internal memory and configure a structure for the “Software Boot Config” (section 25.4.4.4 in TRM) and then update the pointer in scratch memory on the OMAP. I then issue a software reset. 

 

It would boot into NAND correctly the first time. But after I configured the System Boot Config it booted into NAND flash again. It would keep doing this cycle indefinitely.

 

I have the output of this program (listed below) that shows the tracing of the ROM bootloader and the system reset status over the cold boot and then the software reset.

 

Notice on the first execution the Software Boot Config is not initialized (its initialized after this output). The reset status is a cold reset (POR) as expected. The tracing of the first ROM execution is as expected also.  The pointer in scratch memory was also garbage before I initialized it.

 

On the second boot  the Software Boot Config is correct (read from the internal memory).   The pointer to Software Boot Config in scratch memory also points to my expected internal RAM address.  According to the ROM bootloader tracing after the reset its stating the following:

  1. It was not executed after a cold reset.
  2. It did not verify my Software Boot Config booting section.

 

 

 

Texas Instruments X-Loader 1.4.3 (Apr 30 2013 - 12:29:39)

Reset Status = 0x1

SoftBootConfig U32 1  0x4430f88c

SoftBootConfig U32 2  0xb7902d81

SoftBootConfig U32 3  0x28a63869

SoftBootConfig U32 4  0x0fd5c989

SoftBootConfig U32 5  0x0dc4c10a

Sys Boot Pin Values = 0x3b

Current Trace word 1 = 0x0045085f

Current Trace word 2 = 0x00020004

Current copy of PRM_RSTST = 0x00000001

Cold reset trace word 1 = 0x00000000

Cold reset trace word 2 = 0x00000000

Software Boot Config Pointer  = 0x8ec7dae1

Current Boot = 0

 

Texas Instruments X-Loader 1.4.3 (Apr 30 2013 - 12:29:39)

Reset Status = 0x2

SoftBootConfig U32 1  0xcf00aa01

SoftBootConfig U32 2  0x0000000c

SoftBootConfig U32 3  0x00060000

SoftBootConfig U32 4  0x00060006

SoftBootConfig U32 5  0x0dc40006

Sys Boot Pin Values = 0x3b

Current Trace word 1 = 0x0040081b

Current Trace word 2 = 0x00020004

Current copy of PRM_RSTST = 0x00000002

Cold reset trace word 1 = 0x0045085f

Cold reset trace word 2 = 0x00020004

Software Boot Config Pointer  = 0x4020ef00

Current Boot = 1

  • 0
    Prodigy 140 points

    I just want to stress this is not a booting issue.  I can boot into either the NAND flash or the MMC/SD if the strapping of sys.boot is set correctly. 

    Due to a previous board production the sys.boot strapping has to remain at NAND and I want to transition the boot after the next software reset to the MMC/SD using the Software Boot Configuration.

    Diff for board.c was added. 

     

  • 0 in reply to steve miller4
    TI__Genius 15510 points

    In the past I've helped a customer with software boot config. I think the sequence below worked for them:

    0x48002910         C0 29 00 48          pointer to boot config

     Boot config

    0x480029C0        01 AA 00 CF         sync key for section 1

    0x480029C4        0C 00 00 00          size of section 1

    0x480029C8        1E 00 06 00          disable all CH, first boot device MMC1

    0x480029CC        05 00 06 00          second boot device MMC2, third boot device MMC1

    0x480029E0         05 00 00 00          fourth boot device MMC2, 2 bytes of padding

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 140 points

    This did not work for me.  In fact it hung my x-loader.  According to the OAMP35x TRM  address 0x48002910 is mapped into the L4 SCM memory. 

    System control module (SCM) 0x4800 2000 0x4800 2FFF 4KB Module

                                                           0x4800 3000 0x4800 3FFF 4KB L4 interconnect

    Is there a preferred memory space in the internal RAM that the boot ROM want us to us? 

    I tried the same internal memory space I used before but with the FLAGs set to  0x001E.  It booted but again did not accept the Software Boot Config.  

    I'm also on a little endian config so I converted your data to little endian.  What endian does the boot ROM use?  I tried a quick test swapping the endian but that failed also. 

    Steve 

  • 0 in reply to steve miller4
    Prodigy 205 points

    Has there been an update to this issue?

  • 0 in reply to and
    Prodigy 140 points

    No there has not  :( 

  • 0 in reply to steve miller4
    TI__Genius 15510 points

    The board I worked on last year was either OMAP35xx or AM37xx. Definitely little endian, but the code I used to dump memory displayed it the way I posted earlier.

    You cannot use the internal RAM at 0x40200000 since the boot ROM will use internal RAM for booting. The area you must use is the scratchpad memory starting at 0x48002910. Look at section 25.4.4.4 in the TRM (I have an older TRM, but the section should be the same in newer). I tried to copy/paste but it didn't look so good.

    "The SW booting configuration is stored in the special scratchpad memory, which is not cleared after SW resets or wake-uos. The SW booting configuration is a simple structure located at the address that is stored at the first location of available scratchpad memory: 0x48002910."

    So at 0x48002910 you would have a pointer to the structure. So in my previous post, I had 0x480029C0 at 0x48002910 and then filled in the structure starting at 0x480029C0. I can dig up an OMAP35xx or AM35xx or AM37xx platform and test it out again. I should work the same way on all three platforms.

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 140 points

    Thanks Steve 

    After I reviewed your memory addresses again I realized it was in the scratch pad memory space. 

    The internal RAM I was using was at an unused space that the bootloader was not going to overwritten by the download or execution of my program. 

    After I repeated your address pointers (using the scratch pad memory) and removing some unnecessary code (it was an x-loader I modified to test this out) I was able to successfully boot from the NAND to the SD card  with the software boot config. 

    So it seems that this structure must be in that scratch memory space to be used  (i.e. valid Internal RAM of the OMAP can not be used).

    Thanks for your help.