loading u-Boot in memory instead of flashing it

Question

In my ARM based custom board, I flash u-boot to NAND whenever I do changes on that. (putting some debug statements/modification). Is there any way to directly load the uboot image in RAM memory instead of flashing it every time?

For linux kernel image I do load it in memory and use bootm to boot that image. Similarly for u-boot I am trying out. Kindly provide your suggestions.

Solution 1

Someone at Freescale has done this, for their P1022DS evaluation system (and some others as well). They have provided a somewhat useful document about the process in the file ${UBOOTROOT}/doc/README.ramboot-ppc8500 (in U-Boot V2010.12). This document is pretty terse and leaves many questions unanswered, but I found it a reasonable place to start when I needed to debug U-Boot for a new board, before the flash memory for that board was operating correctly.

In fact, having non-functional flash memory is one reason you might want to debug U-Boot in RAM. (There are a few reasons listed in the README, and they all sound pretty reasonable to me, in contrast to some of the other advice available on this subject)

In our situation, it was found that early prototype target board hardware included an error in the address bus connection to the flash memory that prevented us from using that flash memory. While the hardware was being redesigned and re-fabricated, we wanted to continue testing/debugging those parts of our U-Boot configuration that did not depend on flash memory, for example, I2C, Ethernet, FPGA configuration, PCIe, etc. (there are plenty of things that are independent of where the U-Boot image comes from).

Running U-Boot after loading it into RAM via a JTAG interface (using Codewarrior and the USB TAP) allowed us to continue our U-Boot bring-up tasks, even though we had no functional flash memory. Once we received a newer version of the target board with correctly functioning flash memory, we returned to debugging those parts of U-Boot that we hadn't been able to test earlier. After that, U-Boot was fully functional, and we did not have to wait for a board spin to make any progress.

Solution 2

Debugging a bootloader is a bit difficult, but with the right tools it should be relatively painless.

I deal with the PowerPC achitecture and with a BDI-3000 I can load and debug directly to RAM (of course, after initializing the DDR controller).

One option is if you have on-chip SRAM or L2 Cache that can be configured as on-chip SRAM. The BDI can copy to the SRAM area first, u-boot does it's thing (initialize DDR controller for example), then relocates itself to DDR RAM afterwards. Definitely faster that re-writing to slow Flash all the time.

Solution 3

It wasn't possible in 2004, at least.

Solution 4

It should be possible, if the U-Boot image you want to run has startup code that allows running it from arbitrary addresses. Whether or not that is the case for your board I can't tell.

If the startup code begins by copying the code section from the current (PC-relative) address to the final execution address (usually this is preceded by a check that these areas don't overlap), then you can load the .bin file to any address in RAM, and invoke it using go.

The second obstacle I could see would be unconditional RAM setup code at the beginning, which a number of boards have.

Solution 5

This is what can be read on the u-boot documentation FAQ:

Question: I don't want to erase my flash memory because I'm not sure if my new U-Boot image will work. Is it possible to configure U-Boot such that I can load it into RAM instead of flash, and start it from my old boot loader?

Answer: No. (Unless you're using a Blackfin processor, or Socfpga board, but you probably aren't.)

Question: But I've been told it is possible??

Answer: Well, yes. Of course this is possible. This is software, so everything is possible. But it is difficult, unsupported, and fraught with peril. You are on your own if you choose to do it. And it will not help you to solve your problem.

source:http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

View more solutions

Comments

[Chris Stratton]

I am going to say that it should be possible - it is certainly common with a number of version of u-boot. Even if the processor wants to monkey with ram, refresh settings, etc in a destructive way on boot, with proper design it should not even be necessary to reset the processor to start a new version of u-boot from the old version.

[Jim Chargin]

This post was made in error, I apologize. I was not ultimately successful in using the Freescale document to start U-Boot in RAM.

[Chris Stratton]

That's not necessarily true. There are targets where loading a trial u-boot from a flashed u-boot is supported and considered entirely normal. And it can be a handy way to test!

[timmins]

I got this to work successfully for the P1010 without much trouble, so other readers shouldn't be deterred. It is very useful if you don't have a BDI debugger. link. Note that the "CONFIG_SDCARD" bit is misleading, all you really need to do is set #define CONFIG_SYS_TEXT_BASE 0x11000000 #define CONFIG_RESET_VECTOR_ADDRESS 0x1107fffc #define CONFIG_SYS_RAMBOOT

[Vendetta V]

'load usb 0x<memory_address> u-boot.bin' Above command should include the usb device that you need to write to load USB <device:id> 0x<memory_address> u-boot.bin eg: load usb <0:1> 0x<memory_address> u-boot.bin