[LinuxBIOS] A very good idea

ron minnich rminnich at gmail.com
Fri May 4 19:22:20 CEST 2007


On 5/4/07, MARTIN WOODHOUSE <hokusai at btinternet.com> wrote:

> ---- What should happen ---- it seems to my ancient mind --- is that the
> programmer should merely write a series of in a form such as :
>
> processor=xxxxx
> primaryRAM= yyyyy
> videochip=zzzzz
> etc
> etc
>
> --- and so forth, for whatever components are known to have the need to be
> handled,

speaking of reinvention ... this is LinuxBIOS V1 :-)

But ...

The primaryRAM idea won't work. RAM can move around, be at different
CPUs, and so on. It's totally dynamic. The timing is dynamic. The bugs
are dynamic. The videochip idea won't work either. Yes, this problem
seems that simple but, no, it's not nearly that simple. Dealing with
this complexity is what has driven LinuxBIOS to its current complex
form.

The best you can do, for real hardware, is to give the code some
hints. This set of hints then turns into a sea of conditionals at
runtime: you may or may not have all the CPUs, memory may only be on
one CPU, the video may be on CPU 0 or CPU 1 (as in Sun ultra 40), and
so on. Some parts have bugs, so you have to build in the workarounds.
Some mainboards have bugs-by-design, so you may have all the chips you
want, but you still need to fit in those mainboard bugs. And on and on
...

And that's why, there is a V2. Because around 2002 or so the hardware
got very complex, and much more work needed to be done at runtime, and
the structure of functions and the order in which they were called got
pretty messy.

As to this OFW and LinuxBIOS discussion: LinuxBIOS is designed to load
an OS from FLASH, no more and no less. To the maximum extent possible,
LinuxBIOS avoids drivers, file systems, network protocol stacks, web
servers, icons, GUIs, video displays, and so on. There is a reason for
this: I have seen, over the years, that BIOSes tend to do a poor job
of supporting hardware; conversely, OSes like Linux do a very good
job. Hence the original design goal of LinuxBIOS: to facilitate
placing a Linux image in FLASH, and using Linux as the BIOS. Hence the
name.

In fact, in the early days, we did not consider what we now call
"LinuxBIOS" as separate from a Linux kernel. The payload was always
Linux. The only thing that required the seperation, eventually, was
the small FLASH sizes and the Linux kernel bloat.

OFW is also an OS, really like Linux in a way. In fact, OFW is much
more like Linux than it is like LinuxBIOS. It has drivers, file
systems, console interaction, network protocol drivers and stacks (and
now, even an 802.11 stack and OFW supplicant), a simple GUI, icons,
interrupt support (in some versions), etc. etc. Some implementations
have had threads and/or processes. OFW seems to really want that
console interaction -- the standard fallback is an 'ok' prompt. In
many situations, however, console interaction is impossible, which has
been an issue with clusters I have built based on OFW-based systems
(i.e. SPARCs).

That's one reason that LinuxBIOS is <32K, and OFW is 32K*10 -- even on
a trivial platform like OLPC. OFW does a lot more. The extra
capability of OFW makes it very powerful, and that is both a strength
and a weakness.

There are two things that OFW does that I am uncomfortable with. The
first and most important is, as mentioned: it has lots of drivers. If
you are planning to run, e.g., OFW AND  Linux on new hardware, you now
have doubled the task of writing drivers: you get to write BOTH Linux
and OFW drivers. Now, people tell me all the time that drivers are
easy. Generally, these are people who are either really good at
writing drivers, or who have never had to wring the last
almost-never-happen bugs out of a driver. It is true that the first
iteration of a driver is pretty easy. What makes them miserable is
managing all the corner cases and hardware bugs and
only-happens-once-in-100 million iterations bugs. So, for example, one
of my OLPC units will still not talk to ANY of my flash sticks ...
from OFW. From Linux, these flash sticks work fine -- and always have.
They worked fine when we used Linux-As-Bootloader. Yep, this can be
fixed, but it does point out the issues that come up with supporting
two different operating systems on one piece of hardware. Each one has
to work, and they have to interact and work together. It's more than
twice as complex, because of those interactions, as Jordan alluded to
in a recent note.

The drivers require support, but the support team for OFW is probably
1/1000 the size of the support team for Linux, and, I guess, has about
1/1000 the money to do the work -- I think this is an optimistic
estimate. So, which group will fix bugs faster, and be more current on
hardware? I think I can guess. That's why I like Linux as the BIOS. It
gets back to support.

I don't believe that OFW will ever have the level of support that
Linux has. It is an OS, but it is not the OS people run; it just boots
an OS. That distinction is guaranteed to put OFW behind Linux in the
queue for support money and people. And, further pressure applies,
because the chipset vendors are making it very clear to third-party
vendors that their BIOS support teams should be writing EFI drivers,
not OFW or other BIOS drivers. Whatever time and money the hardware
vendors have for driver writing breaks down something like this:
1. boot support for traditional BIOS / EFI driver
2. Windows drivers
3. Linux (maybe) drivers (you can tell by the quality of some of these
drivers ... )

I've seen this directly. We talked to one company, who told us they'd
be showing us some really neat cluster hardware "as soon as we have
finished up our EFI drivers". Yes, they are writing EFI drivers from
scratch, although they have existing Linux drivers. Why not boot Linux
from FLASH? An interesting question. It would require some chipset
vendor support, I suppose. :-)

I talked to someone yesterday who built a small OS for an infiniband
appliance. They actually got it to go. They also swore that the next
time, their firmware was going to be simple: "Load Linux from flash
and go -- let Linux do it". That's been our rallying cry from the
beginning -- let Linux do it.

One might ask, instead of merging LinuxBIOS and OFW, why not merge
Linux and OFW? After all, we have shown that we can boot Linux from
FLASH, and it can be fast. Linux has great driver support. Linux has a
huge support team, and support from many corporations. So why not
subsume OFW into a Linux module? I think this could work, for people
who really want OFW, and makes more sense than merging LinuxBIOS and
OFW.

I think, for the future, where small 512KiB flash parts exist, the
LinuxBIOS+OFW combo makes sense, for those who need OFW capabilities.
And, as we have seen, on a sufficiently simple platform such as OLPC,
OFW can do a great job without LinuxBIOS. I could post the OLPC
startup code, I guess, but it's really a loop something like this:

for(i = 0; i < COUNT; i++)
   wrmsr(table[i].msr, table[i].value);

Done. It's a tad more than that, but not by much. Few platforms are
this simple.
It's also quite possible that the OFW guys will get motivated to
support K8 -- you never can tell, and the OFW people are very smart
people.

But, even if OFW ran on everything LinuxBIOS ran on, the OFW problem
remains. OFW is a small OS, but it is an OS. If OFW is to boot an OS,
such as Linux, then it will need the platform drivers. Let's suppose
that OFW is ported to a mainboard such as the MS9185. It would have to
support a lot of devices, and they would all have to be written. From
what I can see, a given OFW port to a platform is far more complex
than a LinuxBIOS port, due to the driver issues.

Were OFW to grow, it would require the level of support required of
any OS. It will never get that level of support, period. I actually
find that regrettable. OFW would have been a far better path to take
than EFI. I have never understood the decision, given the existence of
OFW, for the creation of EFI (well, actually, I do understand it, and
that's almost worse than not understanding it ... ). But that decision
has been made, and we are not going to be able to reverse it.

We might suppose that a company or companies would step forward to
support and use OFW
instead of EFI. The question is, how much support should a company put
into an OS which is merely there to boot another OS? Or, to put it
another way, given two choices:
1. use Linux in FLASH to load OS from disk
2. use OFW in FLASH to load OS from disk
which one makes more sense, economically, including costs of support,
documentation, and training? I've talked to a number of companies on
this issue. Last summer, I offered one company OFW; the company knew
what it was, and the response was immediate and negative; "No OFW. Put
Linux in there. Our people know what it is, we don't have to train
them on it".

My second concern is that OFW also makes what I think is a mistake, in
that it supports callbacks into OFW. BIOS callbacks made sense in the
1970s. They even made sense into the 1980s. But as of the 1990s, when
NetBSD on SPARC came out, one of the big NetBSD improvements over
SunOS was to REMOVE the OFW callbacks for console I/O, i.e. to reduce
the use of OFW callbacks. I am not convinced callbacks make sense any
more.  We have seen on many thousands of platforms that we don't need
them.

BIOS callbacks complicate OSes in situations such as SMP -- you have
to make sure the BIOS itself is SMP-safe, or you have to do nasty
things in the OS to support the non-SMP-safe BIOS. I've seen systems
with BIOS callbacks that were not SMP-safe (early EFI machines) and
debugging them was quite hard. It would be nice to use the use of BIOS
callbacks decline, rather than increase. The latest OFW patches to the
kernel institutionalize the BIOS callbacks used on OLPC. I wish that
had not happened.

BIOS callbacks also complicate virtualization (think Xen and friends).
A privileged OS (domain 0 in Xen) can make those OFW calls, but how do
you manage domain 1 and up OFW calls? It is surely a Simple Matter of
Programming, but do we really need to add this complexity to what is
already a pretty complex world? I would rather not.

Of course, the "guest domains" can just figure out they can not
callback to OFW, and get the information some other way. But if an OS
can get what it needs without a callback, why add a callback? Why add
something to an OS when you can do without it?

So, by all means, LinuxBIOS can be bundled with OFW. I think it can be
a useful combination, for situations where there is not much FLASH
memory. That situation is becoming less and less common, but it still
exists .

While I think OFW as a payload makes sense in some situations, I don't
see much value in a codebase merge. LinuxBIOS with OFW is useful.
LinuxBIOS without OFW is useful. So, we need to be able to make OFW
optional. That "optional" nature makes a strong case for OFW as a
payload.

At the same time, I believe that as the FLASH sizes grow to 2 Mbytes
and beyond, putting Linux in FLASH will be the preferred option for
many situations. That mode is already common in the non-x86 embedded
space. It's probably the fastest way to boot Linux. And, from my
measurements, Linux is a very fast bootloader -- on processors running
at  2 Ghz, it's the fastest by far. So for people who really want OFW,
maybe an OFW kernel module or OFW shell makes sense, running as part
of Linux. If OFW were integrated into Linux, the driver issue would
disappear.

Long term, however, I can not see the need for anything as complex as
EFI or OFW when one can boot Linux directly, and have Linux boot
Linux. At the FOSDEM conference a number of speakers showed Linux
booting in well under a second -- this on a rather slow ARM. There's
no fundamental reason that we can't boot Linux quickly and use it as
either our embedded OS or bootloader.

To put it another way, the "LinuxBIOS or OFW" issue is the wrong way
to look at the problem, in my view. LinuxBIOS and OFW work quite
nicely together, as we have seen. It's an OFW or Linux issue. Which
one would you rather interact with at boot time? I think, in some
cases, the answer is "OFW", and in other cases, the answer is "Linux"
or "Filo" or something else. Increasingly, however, I think the x86
world will follow the path of the non-x86 world, and the answer will,
increasingly, be Linux -as- BIOS, which means Linux in FLASH.

thanks

ron




More information about the coreboot mailing list