New subject: Random comments on LinuxBIOS

16 Apr 2003


      "McMechan, James W CIV" james.mcmechan@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

Re: Random comments on LinuxBIOS