• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1065 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 x-loader and u-boot from SD, flashing NAND automatically

John F.
Intellectual 830 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I would like to boot from SD to flash a bare OMAP3530 board without changing sys_boot pins so that the user can bring up a bare board. With no card plugged in, it should boot from NAND.  Bringing up my board with JTAG, flashing and running from NAND works fine. sys_boot[4-0] pins are 01111, so I assume MMC1 should proceed NAND.

I'm using x-loader from Arago.  The MLO I copy to SD card runs, but fails to load u-boot.bin, also on the card.  The function get_mem_type() returns 0x0001, so x-loader in start_armboot() decides to get u-boot not from SD but from NAND, which in my test state is empty.

Is there a way to have x-loader look for the secondary bootloader on the same medium from which it was loaded?  I get the feeling this might require patching x-loader source, but hoping this has been done since this page: https://gforge.ti.com/gf/project/bootloader/wiki/?pagename=X-Loader seems to have a version which gets its secondary bootloader from SD or NAND.

I've seen this page: http://processors.wiki.ti.com/index.php/How_to_Flash_Linux_System_from_U-boot , but I'd like a procedure that requires no user interaction besides inserting a magic SD card.

Thanks!,

John

  • 0
    TI__Guru* 86180 points

    This type of boot already works on the OMAP3EVM, so I'm guessing there is some issue accessing the SD card on your hardware platform.  Is it possible that xloader is changing something that is rendering the SD card inaccessible, and then the get_mem_type just defaults to the NAND?  You may want to check to see if xloader believes there is a valid SD card out there.

     

    Regards,

    James   

  • 0 in reply to JJD
    Intellectual 830 points

    Hi James,

    The SD card seems to work fine since when I bring up the board manually to a u-boot prompt with JTAG I see files with "fatls mmc 1", and x-loader/MLO on the card starts ok.

    I'm not sure why get_mem_type() in x-loader is returning 0x0001 since it's reading the sys_boot pins state from the 3530's CONTROL_STATUS register instead of the 01111 state to reflect the voltages on the pins.  I've read through the TRM spruf98i chapter on initialization, and I see the how the boot order is determined, but I didn't see a way for software to determine which boot source the ROM had actually used.  It might be nice for x-loader to see that the ROM had loaded x-loader from SD (from a register) so x-loader could look for u-boot from the same place (SD) instead of reading the sys-boot pins.

    It looks like x-loader is no even trying SD boot just from the CONTROL_STATUS register value and falls through to NAND.  I've seen several versions of x-loader floating around, so maybe there's a better one to use for SD boot versus the default Arago source, unless there's a way to configure it differently.

     

    Thanks,

    John

  • 0 in reply to John F.
    Genius 3685 points

    For future reference for others finding the post in a search in the future, please see http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/69542/252587.aspx#252587 for ways of finding actual active boot device...

  • 0 in reply to Soren Steen Christensen
    Intellectual 830 points

    The approach I ended up taking was: patching x-loader so that it always calls mmc_boot() in start_armboot() regardless of the sys_boot pins' state. This gets u-boot from SD running for me.  To reflash my NAND from files on the SD, I created a boot.scr script with mkimage which erases NAND, reads files from SD then writes to NAND like how it's done in the PSP3's scripts/omap3530/reflash-micron.txt. The boot.scr is put on the SD card with MLO.

    I create the script with:

    mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Flash from SD' -d boot.cmd boot.scr

    , and boot.cmd looks like:

    # a bunch of setenv's like reflash-micron.txt

    setenv rf_all  run rf_xl\; run rf_ub\; run rf_kn\; run rf_fs
    setenv bootargs console=ttyS0,115200n8 noinitrd ip=none root=/dev/mtdblock4 rootfstype=jffs2
    setenv bootcmd nand read.i 0x80000000 280000 500000\; bootm 0x80000000
    setenv bootdelay 3

    echo == Reflashing ==

    sleep 2

    nand erase

    run rf_all

    saveenv

    echo == Remove the SD card and cycle power ==

     

    Probably a better way to decide where to get the secondary bootloader is to use the 3530's booting parameter structure or tracing as suggested.

    ,

    John