Date: Mon, 18 Feb 2013 11:47:03 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: Werner Thie <werner@thieprojects.ch> Cc: freebsd-arm@freebsd.org Subject: Re: RPi hangs in bootloader Message-ID: <A63BA7A1-50C7-4C17-A3F2-D7ADDBCA3001@freebsd.org> In-Reply-To: <51227033.3070304@thieprojects.ch> References: <51227033.3070304@thieprojects.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A63BA7A1-50C7-4C17-A3F2-D7ADDBCA3001>