[LinuxBIOS] Specifications

Stefan Reinauer stepan at coresystems.de
Fri Jun 15 15:56:01 CEST 2007

* Peter Stuge <stuge-linuxbios at cdy.org> [070615 02:08]:
> I think so, for the specific case of the console serial port (or a
> replacement).
> The serial port (or replacement) is crucial for developers and
> initially it was also crucial for users. Those users are still
> around but now we also want to help users that consider other
> devices to be crucial.
Yes, serial port is at least crucial until we get linuxbios shipped on
a given board as default boot firmware
> > I think LinuxBIOS is there to initalize and enumerate the hardware
> > at a very low level.  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.
> This is a very important point and I agree completely.
> LinuxBIOS is not a set of drivers and does not provide services.
So are you saying we should drop VGA init from v3 completely and make
that a seperate payload? While rather working on making payloads
executable serially than to push this code into LinuxBIOS?

But then the LB table needs to be enhancable by any payload any time

LinuxBIOS should provide all information it knows about the hw to the
code that runs afterwards. This "we leave everything undefined" game
does not work out. Because no one else feels responsible to change the
"undefined" state later on either. The bootloader does not care except
for the boot device, the OS does not do the job.  Houston we have
a problem. Bringing the hardware into a defined state is what we want.
Power on default can very well be a defined state for many/most devices.

> Software needs system buses to be in a "working" state where devices
> are "reachable" and some of us considers this to imply that devices
> are "initialized" and set to some state because they have in fact
> been touched while others consider only the bus itself to be
> initialized.

One example is VGA. It's not a bus. But if you are saying it is not the
BIOS' task to enable VGA. Whose is it. The bootloaders?  Come on, that
would not be an improvement of design. Also we have more bootloaders
than we have low level firmware. It would be a desaster for the workload
and thus stability of bootloader writers. Calling a VGA option rom in a
bootloader is about as wrong in my opinion as initializing DRAM in an OS
kernel is. 

Initializing VGA in the kernel is too late for 90% of real world applications.
Imagine someone wants to change the boot device. And no, we do not have
16MBit flashes to pack Linux into on most systems. Not this year and not
next year. And the opportunities in 2009 should be discussed, but not
be a problem for our use today.

> Devices are never _driven_ by LinuxBIOS after the payload has been
> started however, and most devices aren't driven before the payload
> starts either.
Most devices, like video output do not need to be driven. Drivers in
LinuxBIOS context means initialization. Thats all LinuxBIOS ever does:
Initialize HW. No, no sound cards. But: Basic I/O subsystems. The
machine needs to talk to us.

The first computer I was working on was an ITT3030. It's firmware would
have you start the OS loader from disk by typing a blind sequence of
debugger commands into the firmware prompt (that I never saw, I had no
idea about a console at the time. I just knew the sequence). I feel we
should not go back to 1984 or earlier with our standards.

> However - LinuxBIOS will need to "hand over" the system to the
> payload and I guess that the formalization of this handover is what
> this thread is all about. 

honestly, I dont think so. The handover is loading an ELF file. How
unformalized can that be. 

> It should include providing the payload
> with information about how the system is set up as of now so that
> good payloads can be written which will work on any setup.


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