• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 3415 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 OMAP3530 from UART, NAND and MMC

Dan Jordan
Prodigy 100 points

Hello,

I've been trying to create an x-loader image which will allow me to boot my beagleboard from UART, NAND and MMC. I've encountered some difficulties. With some, I've managed to cope, with others, not so much.

Booting from NAND and MMC is pretty straightforward. However, wherever I looked, I saw that in order to boot from a UART, I had to compile my x-loader in the labrador-download configuration, as described here http://elinux.org/BeagleBoardRecovery#UART_recovery. I find this a bit bizarre - why compile to a different board configuration only to boot from UART? And from old and somewhat unmaintained git repositories?

Whenever I tired boot from UART using my own-compiled x-loader, the board would get stuck. (And not flash the leds, as it is written in the appropriate hang() function in the x-loader). (The x-loader was compiled from the Sakoman x-loader git repository, without any changes made in the code according to the omap3530beagle configuration).

I've encountered this message (http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/29688/103210.aspx) which directed me to the TEXT_BASE definition. After looking at the code, I concluded that the labrador-download configuration disables the MMC and NAND support, and immediately runs the UART initialization, and changes the TEXT_BASE definition to 0x40208800 (as opposed to the 0x40200800 in the Sakoman git repository).

Editing the x-loader source, after disabling the MMC and NAND initialization (under start_armboot() in lib\board.c) and changing the TEXT_BASE (under board/omap3530beagle/config.mk) to comply with the labrador-download configuration, I've managed to load the x-loader an u-boot via UART using the u-boot utils (http://github.com/nmenon/omap-u-boot-utils/). Great success!. However, whenever I try to enable the MMC initialization, I get stuck at the mmc_init() function.

Booting from MMC with the TEXT_BASE set to 0x40208800 fails (as opposed to booting with the same x-loader image from UART which works just fine).

Memory wise: I've looked at the SRAM, and saw that the x-loader is indeed loaded to the given address. I don't know how it got there.

 

To narrow it down, I think There are several things I don't understand:

* Why does the MMC init get stuck when I boot from UART? Could it be that the ROM bootloader initializes the MMC differently when it boots from UART than when it boots from NAND/MMC?

* How is the x-loader loaded to the right address? What is the ROM bootloader (first stage bootloader) doing there? Why doesn't it work when I use the default address, but it works when I use 0x40208800?

* How does the ROM bootloader know where to start running? There are no NOPs before the x-loader. According to the TRM, the image is loaded to 0x40200000.

* Is there a good reason not to be able to boot from UART, NAND and MMC from the same x-loader image? I don't think space is an issue, as opposed to the comments in the labrador-download configuration.

 

Thank you for reading, any response would be very much appreciated.

 

Dan.

 

  • 0
    TI__Genius 15510 points

    Since this is a Beagleboard, you might want to ask your questions over at beagleboard.org. In the mean time, here are a few answers.

    The x-loader must be "signed" with the signGP utility. It puts a two word heard in front of the x-load.bin image: The first word is the size of the image while the second word is the load address of the image. The boot ROM reads these two words. Then it reads the image from NAND and stores it at the address in SRAM that was in that second word.  A hexdump of a signed x-loader follows

    00000000  74 5d 00 00 00 08 20 40  12 00 00 ea 14 f0 9f e5  |t].... @........|
    00000010  10 f0 9f e5 0c f0 9f e5  08 f0 9f e5 04 f0 9f e5  |................|
    00000020  00 f0 9f e5 04 f0 1f e5  60 09 20 40 78 56 34 12  |........`. @xV4.|

    You can see that the image size is 0x00005d74 and the load address is 0x40200800. After the image is copied into SRAM, the boot ROM jumps to that address.

    The load address is specified when you build the x-loader.  If you look in x-load/board/omap3530beagle/config.mk you will find this line

    # For XIP in 64K of SRAM or debug (GP device has it all availabe)
    # SRAM 40200000-4020FFFF base
    # initial stack at 0x4020fffc used in s_init (below xloader).
    # The run time stack is (above xloader, 2k below)
    # If any globals exist there needs to be room for them also
    TEXT_BASE = 0x40200800

    So all code is compiled relative to that start address.

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 100 points

    Hello Steve,

    First of all, thank you for your answer.

    I've tried using the x-loader with and without the signGP header. After looking at the different UART loading examples I found, I saw all of them were using the unsigned version of a compiled x-loader. After reading your message I've tried sending a signed x-loader, it didn't work.

    From article 25.4.8.3 in the TRM (revision H): "The peripheral booting image does not have any header and starts directly with executable code". I think that opposed to loading from NAND and MMC, the UART code is loaded to the beginning of the SRAM (0x40200000) and starts running from there, and not directly copied to the destination address (using the GP header).

    After posting the presvious message, I kept digging deeper, and got to the assembly code. I've looked at cpu/omap3/start.S, and saw that at the 'next' function, there is a test of the position of the code: if the code was loaded to the TEXT_BASE address, there's a jump to the next part of the code. If not (UART case), then the code is copies to the TEXT_BASE address.

    I've noticed that when copying the x-loader image, the x-loader copies itself onto itself - and that is what causes the hang. For example:
    Suppose the x-loader image size is 0x6000, and the TEXT_BASE is set to 0x40200800. Then when copying using the copy_loop function, starting from 0x40200000 copying to 0x40200800, the x-loader will copy itself onto itself.
    I'm currently working on changing the assembly code - to change the loop to work from the end of the x-loader to its beginning. I don't know assembly that well, so I'm still debugging.

    If anyone has a better idea (or an already-written code) any help would be much appriciated,

    Dan.