Date: Mon, 18 Feb 2013 18:25:52 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: RPi hangs in bootloader Message-ID: <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> 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 6: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 >> What FDT is: >>=20 >> 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. >>=20 >> How FreeBSD uses FDT: >>=20 >> 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. >>=20 >> 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). >>=20 >> How FreeBSD-on-RPi handles FDT: >>=20 >> 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: >>=20 >> * The RPi boot blocks load the DTB into memory. >>=20 >> * The RPi boot blocks edit the DTB with information about graphics = setup >>=20 >> * U-Boot runs and discovers some additional system information >> (but doesn't deal with the FDT) >>=20 >> * 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] >>=20 >> * ubldr tells the FreeBSD kernel how to access the FDT. >>=20 >> Tim >>=20 >> [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.) >>=20 >> [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. >=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 don't think it can but... > 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? ... you can pass this in on the command line. I think the way we're = booting means we'd have to dig this information out of the environment, = in which case we can always grab the command line... > 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. Let us know how that works out. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C578B82-E8F9-4020-B52C-5F1091576E75>