Random comments on LinuxBIOS

[Eric W. Biederman]

"McMechan, James W CIV" <james.mcmechan at navy.mil> writes:

> > > Here is what I wrote while trying to catch up to list, 
> > though there is a FAQ I
> > > produced this while working my way through the emails 
> > perhaps some of it could
> > > be added to the FAQ
> > 
> > Would you be interested in maintaining or helping to maintain the FAQ?
> > You seem to have a nack for putting the information together.
> > 
> I would be willing, I don't have fast CVS access due to firewall issues but I
> can get a dial up account.
> 
> Where is the FAQ located? Is it just the html or is it backed by some source
> format? it is fairly easy to read as html.

This is where I expect Ron to chime in...  The answers are all in my
head but have not found paper yet.

> > > LinuxBIOS no longer always uses a real OS to load the OS.
> > 
> > That is not quite correct.  
> > 
> > LinuxBIOS requires a real OS, or at least a piece of software
> > that can run standalone without any OS or BIOS services on
> > the bare hardware.  Which is essentially the definition of
> > a real OS though it is not the definition of a general purpose
> > OS.
> > 
> > In the case of ADLO, ADLO can be considered a special purpose
> > OS that mimics the syscall interface of a standard BIOS.
> > 

> I am willing to argue the other way, we no longer "always" need to load a full
> OS we can load elf payloads that are obviously (to users) not OSs, but merely
> boot loaders that don't require BIOS. Even the smallest micro-kernels do a lot
> more than memtest86 for example.

True I guess I just want the distinction to be present that the LinuxBIOS
core does not support callbacks so whatever you run it must be able
to stand up on it's own.  Which is quite rare.

> > In addition there is some background work on secure/trusted 
> > booting.  I don't
> > know if anything has really happened with that yet, but ADLO 
> > grow out of
> > the interest in trusted booting.
> > 
> "grew out of" I assume, but still "trusted booting" has not been discussed much
> recently.  Perhaps I was thinking of Ron's built in VGA ROM stuff, I may have
> also been the first person to suggest bochs as a GPL compatible bios example
> quite a while back. It appears that plex86 is hibernating though Kevin and some
> useful bits of the design have made it over to the bochs project recently.

If you look up the Adams who worked on ADLO trusted booting is their research
area.  I am totally mystified why we have not seen more direct feedback
but I think it is a very interesting area for LinuxBIOS to expand into.
The topic came up not too long ago on the etherboot developers list.  Still
just discussion, but all of the hooks are in the code.

> ...
> > > It would be nice to add a larger flash ROM but many 
> > motherboards do not connect
> > > enough address lines to the Flash ROM socket, for even the 
> > 4 Mbit part or they
> > > solder the chip down.
> > 
> > For LPC flash parts the address line count is not a real 
> > issue, new boards
> > have them and they current are up to 8Mbit in size, but do 
> > not have a theoretical
> > limit.
> > 

> LPC parts are usually soldered down right? 
I have usually seen them in an LPC socketed and in a LPC form factor.

> I have not yet seen one, I thought
> they were part of Intel's new firmware hubs, and most boards I have seen still
> have DIP or PLCC which is why I said "but many motherboards" and should add that
> "new boards with LPC ROMs do not have the pin count limitation."

Newer AMD boards like the AMD760MPX also have it.  Intel's firmware hub is
a variation on the same them.  The difference is which commands are actually
used on the LPC bus.  The firmware hubs have special commands so it is easier
to support multiple devices.  The pure LPC devices don't bother and can just
be strapped to live at the appropriate address.

> > > Steven James had nice comments on Normal/Fallback images:
> ...
> > And after the most recent update the ``hair trigger'' problem has been
> > solved.  In particular it now requires several boot failures in a row
> > before LinuxBIOS switches into fallback mode.  Generally this 
> > is 3 successive
> > failures.
> > 
> I was wondering about that I realized that it had gone in but had not seen where
> people were hitting the hair trigger, is it part of the problem with those
> watchdog timers that keep resetting on people?

A typical problem is when you are installing hardware or other times you
are booting a board and you turn it on and then say darn I was not yet
ready to boot yet.  The result of little issues like that is I was seeing
an unacceptably high number of systems running in fallback.  It did not cause
show stopper problems because my fallback and normal images are not
yet asymmetrical.  But if you can't trust a machine to only be in fallback
when it needs rescue recovery the scheme falls apart.

So basically there was a hair trigger to get into fallback mode, and
now it is some harder.

> ...
> > > hitting reset will boot from the fallback image alone.
> > 
> I was copying verbatim his email it seem like a nice explanation

Right and that was the way the code worked until I updated it recently.

> > The mechanism has been updated to keep a failure count in the 
> > CMOS and only
> > when the failure count crosses a threshold is the boot bit 
> > cleared.  The
> > counter is reset after LinuxBIOS has successfully loaded an image like
> > etherboot.
> > 
> > Etherboot now implements a similar scheme to allow two images 
> > on the disk.
> > One at the start one at the end, but installing an image at the end of
> > the disk still requires some work.
> > 
> I had not seen any messages about etherboot having this. Spiffy

On the documentation side it is also worth nothing the boot order
options.  I can currently specify which class of device to try first
second and third.  In addition I can specify which device of the first
type tried to boot from.

A lot of this was done to support Pink and MCR and now that the code
works I am willing to talk about it.  There was a little mention of it
during the design phaze but mostly there was not much feedback.  And
the discussion really would have occurred on the etherboot list.  Which
is another reason you might have missed it.

> ...
> > > Steve Gehlbach wrote about using BOOT_IDE:
> > > See pcchips787.config in util/config for complete configuration.
> >  
> > Note significant pieces of this information are not using the ELF
> > bootloader, and so describes a deprecated feature.  But it will
> > not be removed in the 1.0.x stable series.  In the development series
> > the code will not be added.
> > 
> I was thinking that it was the clearest explanation I have yet seen on it.
> It could be a elf payload I suppose but currently it is built in.
> Hum, making it into a elf payload would duplicate some of the LinuxBIOS but that
> would not be a problem.
> 
> Also for a elf payload IDE boot I would just suggest Etherboot as the payload.

The case where IDE_BOOT and an linux kernel comes into play is if you have
a system with compact flash and that is the only location large enough
to put it.  But yes, in most instances I would suggest etherboot as well.


> ...
> > > 
> > > Hope this helps,
> > 
> > It Looks like a very good summary.
> > 
> > Eric
> > 
> > 
> Glad you liked it, I was reading a couple weeks worth of LinuxBIOS email at once
> and was bothered by the questions that had, what I thought were obvious answers,
> so I started typing as I was reading then I checked the FAQ and dropped a few
> comments and wrote some more.

Now just to figure out how to get this incorporated into the FAQ.  However
it gets maintained I am certain from this email that it really should
be posted to the list periodically so people just reading their email
will see it and we can point out places it needs corrections just by
replying...  If nothing else it is a good way to draw answers out of my head...

Eric