On Thu, Aug 15, 2013 at 09:04:20AM -0400, Matt Geiman wrote:
Hello all,
I have a quick question that I hope you can help me with. We are running version 2009.11 of u-boot on a Beagleboard based project and are looking to upgrade to the latest and greatest (currently 2013.07). This project has no MMC slot, so originally the only way to initially load the board for the first time was over a serial connection. A previous employee wrote a piece of software (and customized x-loader) that would load x-loader, u-boot, the kernel, and a minimal filesystem into RAM. It (the customized x-loader) would then boot the copy of u-boot in RAM, which would then flash everything to NAND.
So the process is:
- A script waits for the ASIC ID from the board and downloads our custom
x-loader when it's received the ID. 2. The custom x-loader then can accept commands from our script to write the MLO, u-boot, kernel, and FS to RAM. 3. The custom x-loader then accepts a command to boot a certain area of memory, which is what starts u-boot.
Our problem is this; our piece of software and custom x-loader downloads the new u-boot file successfully, however when the custom x-loader tries to boot the new u-boot image from RAM it hangs/fails. According to this:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted...
This page is correct, and a bit of a cop-out. For a large number of reasons, we don't want people chain loading U-Boot booting U-Boot booting U-Boot ...
Of course, SPL is U-Boot, and boots U-Boot fine. x-loader was U-Boot, and boots U-Boot. What's going on is that you need to take care when starting U-Boot, just like SPL does.