Random comments on LinuxBIOS

McMechan, James W CIV james.mcmechan at navy.mil
Wed Apr 16 19:10:01 CEST 2003


> > 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.

> > 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.

...
> 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.

...
> > 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 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."

> > 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?

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

> 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

...
> > 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.

...
> > 
> > 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.



More information about the coreboot mailing list