[LinuxBIOS] Specifications

Fri Jun 15 02:33:28 CEST 2007

On Thu, Jun 14, 2007 at 05:28:26PM -0600, Jordan Crouse wrote:
> On 15/06/07 01:02 +0200, Stefan Reinauer wrote:
> > * Jordan Crouse <jordan.crouse at amd.com> [070615 00:36]:
> > > I disagree.  Letting payloads rely on LinuxBIOS to set up devices is the
> > > start of a slippery slope that we should try like mad to avoid. 
> >  
> > We do know there are devices that won't work if LinuxBIOS does not do
> > the job. RAM, PCI resources, SCSI, VGA, ...
> > 
> > There are plenty of cases where the payload relies on LinuxBIOS setting
> > up the hardware. 
> > 
> > This is the whole point of LinuxBIOS: setting up the hardware.
> 
> I guess it sort of depends on your definition of "hardware". :)
> We do the steps to enable the system to run, and to enumerate certain
> parts of the hardware so that the payload can see them, but we don't often
> make policy decisions for devices hanging off the end of the busses.
> We don't set up IDE drives.  We don't configure sound cards, or initialize
> NICs, or any of those things.

Well, depends on the definition of "set up" or "configure" :)

LinuxBIOS _can_ enable the secondary IDE interface, for example. Or it
may not do it (or disable it explicitly), so that the OS (or payload)
won't see or be able to access that IDE interface. This is configurable.

> The point is, that LinuxBIOS shouldn't
> really be required to leave individual devices in any sort of sane state.

I agree, and the important word here is "required"!

A payload (bootloader, OS, application, whatever) should _not_ depend on
device so-and-so being enabled or setup. In general, it can't do that
anyway. Say you're an OS. You have no idea whether there's a floppy
drive; it may not be present, it may have been disabled by the BIOS, you
just don't know; thus, you cannot rely on it _anyway_. The same is true
for almost all other devices in any modern computer.

Now to the important point (IMHO):

There are _some_ things which a payload _must_ be able to rely upon, and
that's what "we" (LinuxBIOS) must set up correctly. And that's exactly the
stuff we should formally define somewhere as minimum requirements
a payload _can_ rely upon when it's invoked.

This is not much, though. Short brainstorming:

 - RAM must work. It it's not configured, no reasonable payload will
   be able to work. This is the very minimum we _must_ do.

 - ???

That's about it? Everything else is probably optional (in my eyes).
Please make other suggestions, maybe I'm overlooking something, but RAM
is just about everything I can come up with right now.

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.

> Again, words get in the way.  LinuxBIOS does initalize and enumerate it,
> but I don't really think that the intent is to require LinuxBIOS
> to tromp out and touch the 16550 and set baud rates, and other such
> configuration settings so that the payload doesn't have to.  Am I wrong?

Nope, I don't think so.

We _can_ do that (and do it for most boards), but it's an optional
thing. The payload cannot rely on an already setup serial port. And
rightly so.

Some payloads (FILO, GRUB, memtest, Linux) have their own options to enable
serial consoles and that already works great. No need for us to intervene
here. We set up a serial console if _we_ (LinuxBIOS) want to print stuff
to a serial console. We don't care whether the payload which comes after
us wants or needs a serial console. That's none of our business, IMO.

> > Ok, so what would you say is LinuxBIOS' job then? 
> 
> I think LinuxBIOS is there to initalize and enumerate the hardware at 
> a very low level.

Full ack.

Maybe even "at _that_ low level where any other payload _cannot_ do the
job even if it tried to".

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)

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

 - Hardware virtualization features (Pacifica / Vanderpool). My
   understanding is that these -- if disabled by the BIOS -- cannot be
   enabled by any OS(?)

 - ...

This is the sort of stuff which is the "job" of LinuxBIOS, IMO. But
still, this is _configurable_ so a payload _cannot_ rely on it anyway.

> I don't think it is there to be a surrogate serial /
> smbus / IDE / VGA / whatever driver for payloads that don't wish to 
> implement those things on their own.

I agree.

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

There are some potential projects out there where we could borrow code
to implement something like that (with some hacking maybe), e.g. dietlibc,
uclibc, klibc, newlib, FILO, GRUB2, memtest86, busybox, ...

All of them have some sort of keyboard driver, some sort of serial
driver etc. etc.

> Of course, I say that because I'm
> pretty much only interested in loading payloads that do support those
> services on their own - but I personally think one of LinuxBIOS's
> greatest assets is that it does only what it needs to, and puts the
> responsibility on me to do the rest.  The power and flexibility of that
> single trait is worth it. 

Full Ack.

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070615/eddac915/attachment.sig>