RPi hangs in bootloader

[Ian Lepore]

On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote:
> > I do not understand the FDT_ERR_BADMAGIC, the page http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors listed in an example session but does not explain what the message conveys?
> 
> To help me clarify my own understanding, I wrote a brief
> explanation of where we are with FDT handling that
> digs into how RPi boot handles FDT today and points
> out some of the work that still remains.
> 
> What FDT is:
> 
> FDT is a way for the kernel to find out what hardware it's
> running on; there is a DTS (source) file you can edit
> that gets compiled into a DTB (binary) file that is actually
> used to drive the kernel driver setup.  FDT was
> standardized as part of OpenFirmware on PowerPC; it allows
> the system to boot very quickly and allows people who are
> changing hardware configurations to quickly adjust the system
> to match new hardware.
> 
> How FreeBSD uses FDT:
> 
> For a while, we've mostly been compiling the FDT into the kernel,
> but we're trying to move to a better design where the FDT is
> provided by the boot loader.
> 
> This will eventually allow us to use a single kernel on multiple
> systems (the fabled "GENERIC ARM kernel") and make it
> much easier to configure boards (for example, if you connect
> a new peripheral via GPIO, you'll be able to "just" edit the
> DTS, compile a new DTB, and reboot to use that peripheral).
> 
> How FreeBSD-on-RPi handles FDT:
> 
> The RPi is closer to this boot process than other platforms
> (I'm working right now to move BeagleBone in this direction)
> but it's still evolving.  Here's how the RPi handles the FDT
> when booting FreeBSD:
> 
>  * The RPi boot blocks load the DTB into memory.
> 
>  * The RPi boot blocks edit the DTB with information about graphics setup
> 
>  * U-Boot runs and discovers some additional system information
>     (but doesn't deal with the FDT)
> 
>  * FreeBSD ubldr runs, finds the DTB in memory [0] and edits it
>     to contain memory configuration and some other related
>     data that it queries from U-Boot. [1]
> 
>  * ubldr tells the FreeBSD kernel how to access the FDT.
> 
> Tim
> 
> [0] This is the key part that's still not quite right on RPi;
> ubldr should request the FDT from U-Boot whereas right now it
> has special knowledge of how the RPi boot blocks store the FDT
> in memory.  I'm trying right now to teach ubldr how to get
> an FDT from U-Boot.  (U-Boot can get the FDT from the RPi
> blocks, but we are not using that capability today.)
> 
> [1] A less-serious weakness of the current process:  Either U-Boot or
> the RPi boot blocks should be doing this editing, instead
> of ubldr getting the information from U-Boot using a different
> mechanism.

While you're digging around in that area of the code... is there any way
ubldr can find out from u-boot how it was loaded?  I would love it if
ubldr could automatically set currdev=net0: if it was loaded via dhcp or
tftp, and automatically use net0:/boot/loader.rc in that case as well.

If that's not possible, I'd settle for the ability to pass args to
ubldr.  Or even a value in the environment would work I guess, can ubldr
see the u-boot env?

The general thing I'm up to today is learning enough about ubldr to use
it effectively, and ultimately to see if it can be used to load a
(semi-)generic kernel plus a set of modules you configure in loader.rc.
I've just managed to do that by hand, now to see if loader.rc will
cooperate.

-- Ian