[LinuxBIOS] Specifications

Stefan Reinauer stepan at coresystems.de
Fri Jun 15 13:57:03 CEST 2007

* Uwe Hermann <uwe at hermann-uwe.de> [070615 02:33]:
> IDE, SATA, floppy, sound, USB, NIC, serial console, USB console, etc.
> etc. etc. All of that is completely optional. It might be enabled or it
> might not (it's user-configurable). Thus, a payload can (in general) not
> rely on this stuff.
For SATA a payload can often just use a normal IDE driver, if LinuxBIOS
set up some parts of the device, i.e. enable the IDE interface of the
controller or pump some microcode into the controller.

Hey, and then think VSA. We want the VGA device to be VGA compatible,
thus VSA is used to "enable" the hardware. We want to have VSA drivers,
or each payload has to know how to initialize board specific(?) code for
the given system. Bad idea.

> There is some hardware which _has_ to be enabled by the BIOS / low level
> firmware, otherwise no OS or payload can use it:
>  - HPET (which is only half true, there are patches for Linux to
>    force-enable it even if the BIOS didn't enable it)
How do these patches know where the HPET sits?

>  - TPM chip (I guess if the BIOS disableѕ it explicitly no OS can
>    re-enable it again!?)

There are locking mechanisms, but the background here is that you want
a safe boot chain for example, so the LLFW needs to enable TPM to make
sure the payload is trusted, which needs it to make sure the OS is
trusted, etc.

>  - Hardware virtualization features (Pacifica / Vanderpool). My
>    understanding is that these -- if disabled by the BIOS -- cannot be
>    enabled by any OS(?)
Again, some BIOSes lock these, then the OS can't do anything. We don't
enable them, but we don't lock them either. So the OS can do what it

> However, what would be useful is sort of a small "payload library" (which
> is _not_ part of LinuxBIOS) which payloads can use to speed up
> development. That library could be something libc-like or something
> smallish like a 'Serial+VGA+Keyboard-driver'-lib...
Yes, definitely a good idea. Another attempt besides the great
unification is to make sure all of the main payloads work really well.
None of them really does so far - they all have drawbacks.

I think a payload should not need to be compiled for the system it is
going to run on but should be able to ask LinuxBIOS what system it is
running on and go generic from there on.


coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/

More information about the coreboot mailing list