RPi hangs in bootloader

[Tim Kientzle]

> 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.