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: > > 1. 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/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot