Date: Mon, 18 Feb 2013 18:05:12 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <kientzle@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: RPi hangs in bootloader Message-ID: <1361235912.1164.55.camel@revolution.hippie.lan> In-Reply-To: <A63BA7A1-50C7-4C17-A3F2-D7ADDBCA3001@freebsd.org> References: <51227033.3070304@thieprojects.ch> <A63BA7A1-50C7-4C17-A3F2-D7ADDBCA3001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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. 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=net0: if it was loaded via dhcp or tftp, and automatically use net0:/boot/loader.rc in that case as well. 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? 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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1361235912.1164.55.camel>