[U-Boot-Users] Pull request: u-boot-freebsd

[Marcel Moolenaar]

On Dec 17, 2007, at 10:19 AM, Haavard Skinnemoen wrote:

> On Mon, 17 Dec 2007 10:06:07 -0800
> Marcel Moolenaar <xcllnt at 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...

-- 
Marcel Moolenaar
xcllnt at mac.com