Date: Mon, 18 Feb 2013 11:45:58 -0800 From: Tim Kientzle <tim@kientzle.com> To: Werner Thie <werner@thieprojects.ch> Cc: freebsd-arm@freebsd.org Subject: Re: RPi hangs in bootloader Message-ID: <F9C6417F-3D30-46D8-B96C-E1800BC70F26@kientzle.com> In-Reply-To: <51227033.3070304@thieprojects.ch> References: <51227033.3070304@thieprojects.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 18, 2013, at 10:17 AM, Werner Thie wrote:
> Hi all
>=20
> 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
>=20
> > 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 =85
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
>=20
> FreeBSD/armv6 U-Boot loader, Revision 1.2
> (root@xtools, Mon Feb 18 08:36:09 CET 2013)
> DRAM: 224MB
>=20
> 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=3D0x3939b8+0x4294c =
syms=3D[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.
>=20
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9C6417F-3D30-46D8-B96C-E1800BC70F26>