On Dec 17, 2007, at 10:19 AM, Haavard Skinnemoen wrote:
On Mon, 17 Dec 2007 10:06:07 -0800 Marcel Moolenaar xcllnt@mac.com wrote:
I fully realize that for developers who's focus is U-Boot, anything that runs on top of U-Boot and that wants something from U-Boot is a burden at times, but it is important to realize that U-Boot is most of the time nothing more than the first step towards a useful machine and that there can be more than 2 steps in getting on OS to run. The ability to make use of the (hardware) knowledge that U-Boot has, and at the same time its ability to abstract it for the next steps, is in my opinion just as important as having its own prompt.
I agree, but I thought exporting u-boot's hardware knowledge was the whole point of the Device Tree (libfdt) stuff?
It's not that I'm really objecting to the new interface -- it does seem to be more well-designed than the old jumptable stuff -- but it's just that I don't understand why you need this functionality in the first place, just to be able to boot an OS. When you have a kernel image as well as possibly other related images loaded into memory, along with a device tree providing detailed information about the hardware, why do you need a syscall interface on top of everything?
[apologies: I appear to be very verbose this monday morning...]
First of all: It is possible to create a FreeBSD version that can be loaded directly from U-Boot. In fact, that's what we used to do. You don't really need an API in U-Boot to boot an O/S. But, there's a cost. Granted, that cost is not really of any concern to U-Boot, for it's a cost that relates to FreeBSD and it's users, but the cost is there nonetheless.
The FreeBSD loader is in a way an intrinsic part of the FreeBSD O/S in that we depend on the loader for module support, as well as the support for memory disks and we interact with the loader be setting options in files under /boot that the loader uses. Without the FreeBSD loader there's no "module" that creates the metadata used by the FreeBSD kernel to find loaded modules and file systems. This means, in practice, that if you eliminate the FreeBSD loader, you drop support for modules and kluge the kernel to allow for a single memory-based root file system and you tell the kernel where it is loaded by using an environment variable of some sort.
Eh, hang on... U-Boot environment variables can only be read by using the corresponding function from the jump table and as per my previous email, there's no way you can get that without building/configuring a kernel that works with that particular U-Boot copy...
The problem we have by not using a loader is exactly the same, except that it's much harder and much more unwanted to configure a FreeBSD kernel at build time for use on a single U-Boot configuration. We, as in FreeBSD, actually want to build a single kernel that at runtime configures itself according to the hardware it finds itself running on and the FreeBSD loader plays a pivotal role in that desire.
Even while we've not reached our ultimate goal in that respect, we know we will always have to build a loader that matches the platform. We will end up having a loader that works within Open Firmware and we will have a loader for U-Boot (and I'm talking PowerPC based H/W only at the moment -- our collection of loaders is actually bigger). In fact, without a loader we will not achieve our ultimate goal of building, say, a single PowerPC kernel that in unison with the loader runs on, say, AIM hardware and Book-E embedded systems.
Now, let's get to a lower level: we also like to be able to build a single, say, PowerPC-based U-Boot loader that works on any PowerPC hardware that uses U-Boot. We know by looking at U-Boot that that won't be possible if we don't have a layer of abstraction somewhere. And unfortunately for U-Boot, that layer of abstraction is ipso-facto provided by the one component that cannot work with an abstraction of the hardware itself. That is the most ideal and logical software stacking design possible. And that's why we need the API in U-Boot.
So where does the device tree come into play? It doesn't really. All this is about basic functionality to have a 2nd stage loader use the console without having to figure out what all the possible consoles could be and which one of those is being selected in U-Boot. It's about having the 2nd stage loader TFTP a kernel, module, file system, etc by using the network drivers in U-Boot. Likewise, it's about getting a kernel from an USB device without having to have another USB driver when the one in U-Boot just works.
A 2nd stage loader does not need to know about the hardware. It just needs some support for networking and/or disk I/O. The kernel can figure it out by itself. U-Boot is not likely to give the right information anyway, because U-Boot may not even know about all the hardware. A PCI bus scan can be done anywhere. USB discovery needs to be in the kernel anyway. Embedded devices... Ah yes, I can see how U-Boot, being configured for the board, knows about an embedded device that is otherwise not (self-)enumerable. This is where I think the stable API will be extended in the future. In some form. In some shape. Maybe a device tree, maybe not...