RPi hangs in bootloader

[Tim Kientzle]

On Feb 18, 2013, at 10:17 AM, Werner Thie wrote:

> Hi all
> 
> just built a fresh image (latest sources) with Tim Kientzle's script for the RPi after getting my serial cable and see the following on the console
> 
> > cu -l /dev/cuaU0 -s 115200

Context:  You connected after the RPi boot blocks
have already run.  U-Boot's boot delay has just
expired (the digit zero below) and U-Boot is reading
its configuration:

> Connected
> 0
> reading uEnv.txt
> 170 bytes read in 9448 ms (0 Bytes/s)
> Importing environment from mmc ...
> reading ubldr
> 242830 bytes read in 62811 ms (2.9 KiB/s)
> ## Starting application at 0x02000054 …

Context:  At this point, ubldr has started.  ("ubldr" is "the
U-Boot compatible version of loader(8)").
It first probes U-Boot for some general system
info before it prints it's own version information:

> Consoles: U-Boot console
> Compatible API signature found @db662a8
> Number of U-Boot devices: 1
> 
> FreeBSD/armv6 U-Boot loader, Revision 1.2
> (root at xtools, Mon Feb 18 08:36:09 CET 2013)
> DRAM:	 224MB
> 
> Device: disk
> error validating blob: FDT_ERR_BADMAGIC

Context:  ubldr has just run the loader.rc command
that should find the FDT at a particular location in
memory.  Apparently, the block of memory it's
looking at does not in fact contain a valid FDT.
This could be a problem earlier in the boot process
(there isn't an FDT where it should be) or could
be a problem with ubldr (it's not actually looking
where it was told to look) or with loader.rc (it
may not have the correct command).

(Note:  I happen to be tinkering with that exact
part of ubldr at the moment, but I just realized out
that I haven't actually committed any of my changes
yet, so I don't think this is my fault.  ;-)

You're pretty much toast at this point, since without
an FDT, the kernel won't be able to boot.
However, ubldr is going to load and execute the
kernel anyway:

> |
> /boot/kernel/kernel data=0x3939b8+0x4294c syms=[0x4+0x7f530+0x4+0x61597]
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> fdt_start: 0x00466F50
> Kernel entry at 0x100100...
> Kernel args: (null)

The last three messages are printed by ubldr just before
it transfers control to the kernel.  "Kernel args: (null)" is
quite typical here.

> 
> After that the RPi hangs forever. Any hints what to try?

When was the last time you built an image?

There are two reasonable explanations:
  * RPi boot blocks aren't loading the proper FDT into memory.
    Look at the RPi boot configuration file config.txt which
    should refer to devtree.dat.  Make sure devtree.dat
    matches an earlier build.

 * ubldr isn't correctly finding the FDT.   There's been
    a steady amount of work on boot stuff recently, though
    I don't see anything in the last few weeks that seems
    directly relevant.

    Do you know what SVN revision you're using right now?

    Do you have an SVN revision of a recent good build?

Tim