Date: Tue, 19 Feb 2013 09:35:25 -0800 From: Tim Kientzle <kientzle@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: RPi hangs in bootloader Message-ID: <AAC6DACE-6E21-4311-AE1D-9BFB02263550@FreeBSD.org> In-Reply-To: <1361235912.1164.55.camel@revolution.hippie.lan> References: <51227033.3070304@thieprojects.ch> <A63BA7A1-50C7-4C17-A3F2-D7ADDBCA3001@freebsd.org> <1361235912.1164.55.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 18, 2013, at 5:05 PM, Ian Lepore wrote: > 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? >>=20 >> 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. >>=20 >=20 > 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=3Dnet0: if it was loaded via = dhcp or > tftp, and automatically use net0:/boot/loader.rc in that case as well. I believe this is possible, but it would require some C-level work on ubldr. (And I'm not using netbooting in my current dev environment, so I don't have a good way to test this right now.) The U-Boot API does provide a way to access the U-Boot environment variables. My work on ubldr right now is using this to get the FDT information from U-Boot. If I stumble across the specific hooks needed for this, I'll let you know. > 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. Modulo bugs, this should all work. ubldr is just loader(8) with U-Boot API grafted underneath instead of a PC BIOS. So module loading and all the boot-time configuration hooks that people are used to on x86 should Just Work. A couple of folks have talked about turning on FICL in ubldr, that would open even more automation possibilities. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AAC6DACE-6E21-4311-AE1D-9BFB02263550>