[LinuxBIOS] GRUB vs LinuxBIOS question

[Svante Signell]

Hi,

I'm currently reading the mailing list archives on GRUB V2 and LinuxBIOS
development. Can somebody please enlighten me on the interfaces between
the two development projects. In an ideal world one should have open
source, or preferably free software solutions, for the BIOS code too.
Are there any overlaps in functionality that could be synchronised
between the groups? Is anything tutorial-like written explaining the
different functionality of the (Linux)BIOS (CPU, memory, peripheral
initialisation, etc) and GRUB (kernel loading, transfer of control to
kernel etc).

Thanks,

[Stefan Reinauer]

Hi Svante,

* Svante Signell  [051229 17:12]:
> I'm currently reading the mailing list archives on GRUB V2 and LinuxBIOS
> development. Can somebody please enlighten me on the interfaces between
> the two development projects.

I've only been marginally following grub2 development, but the short
answer is: There are no interfaces at all at the moment. The somewhat
longer answer is: From the LinuxBIOS perspective, this is not a bad
thing, as LinuxBIOS tries to keep it's interfaces as small as possible.
There are only two "transitions" between LinuxBIOS and a "client":

1) LinuxBIOS comes with an ELF loader that can load any static self
     contained ELF binary from flash and execute it. This means a single
     binary containing all grub parts that are needed to boot an OS
     could be packed together with LinuxBIOS and burned to flash. So
     far: in theory.

2) There is a mechanism to pass information from LinuxBIOS to the
     outside world called the "LinuxBIOS table". This table contains
     internal information about the BIOS, such as the possible CMOS 
     settings, the RAM map of the machine, etc (there's also E820, 
     PIRQ, MPTABLE and ACPI).

NOTE: LinuxBIOS does not provide any "legacy bios interrupt callbacks",
so no client can call back into the bios to load stuff from the hard
disk. This means a client has to provide a driver for this that accesses
the hardware, not the BIOS. This is why I wrote "in theory" above.
> In an ideal world one should have open source, or preferably free
> software solutions, for the BIOS code too.

Check out www.linuxbios.org and www.openbios.org. From your definition
there exists a small "ideal world" and we are working on making this
available on a much wider basis.
> Are there any overlaps in functionality that could be synchronised
> between the groups?

Basically no. Instead, they both could go hand in hand very well with
only little effort. LinuxBIOS only initializes the hardware and passes
control to a program running in flash which we generally call a
"payload". http://www.linuxbios.org/index.php/Payloads

There are a couple of payloads available for LinuxBIOS:

* OpenBIOS (www.openbios.org)
   * ADLO (http://www.linuxbios.org/index.php/ADLO)
   * etherboot (http://www.linuxbios.org/index.php/Etherboot)
   * FILO (http://www.linuxbios.org/index.php/FILO)

I have been working on taking the grub1 frontend and packing it into FILO 
a while ago. So you can use a grub user interface easily with LinuxBIOS
already (with a reduced function set. patches welcome)
> Is anything tutorial-like written explaining the different
> functionality of the (Linux)BIOS (CPU, memory, peripheral
> initialisation, etc) and GRUB (kernel loading, transfer of control to
> kernel etc).

Speaking for the LinuxBIOS project, the information on www.linuxbios.org 
is getting more and more complete, but we are always seeking to improve
the information there. If you are missing something, drop us a note and
we will try to fix it.

Regards,
   Stefan

[Marco Gerards]

Stefan Reinauer  writes:

Hi,
> Svante Signell  [051229 17:12]:
> > I'm currently reading the mailing list archives on GRUB V2 and LinuxBIOS
> > development. Can somebody please enlighten me on the interfaces between
> > the two development projects.
>
> I've only been marginally following grub2 development, but the short
> answer is: There are no interfaces at all at the moment. The somewhat
> longer answer is: From the LinuxBIOS perspective, this is not a bad
> thing, as LinuxBIOS tries to keep it's interfaces as small as possible.
> There are only two "transitions" between LinuxBIOS and a "client":
> LinuxBIOS comes with an ELF loader that can load any static self
> contained ELF binary from flash and execute it. This means a single
> binary containing all grub parts that are needed to boot an OS
> could be packed together with LinuxBIOS and burned to flash. So
> far: in theory.

In that case it would be easy to create a GRUB 2 binary which can be
loaded from LinuxBIOS.  There are similar binaries to load GRUB 2
using PXE or Multiboot (from GRUB Legacy, for example) already.  I
assume it is little work to implement this.
> There is a mechanism to pass information from LinuxBIOS to the
> outside world called the "LinuxBIOS table". This table contains
> internal information about the BIOS, such as the possible CMOS 
> settings, the RAM map of the machine, etc (there's also E820, 
> PIRQ, MPTABLE and ACPI).
>
> NOTE: LinuxBIOS does not provide any "legacy bios interrupt callbacks",
> so no client can call back into the bios to load stuff from the hard
> disk. This means a client has to provide a driver for this that accesses
> the hardware, not the BIOS. This is why I wrote "in theory" above.

It's possible to add drivers to GRUB 2.  At the moment there are no
drivers there yet, but it surely is possible without too much effort.
> I have been working on taking the grub1 frontend and packing it into FILO 
> a while ago. So you can use a grub user interface easily with LinuxBIOS
> already (with a reduced function set. patches welcome)

It would be nice to have a GRUB 2 payload as well.  I plan to add
drivers in the long term, it's required for several ports.  So it fits
well within the design and direction of the GRUB 2 project, IMO.
> > Is anything tutorial-like written explaining the different
> > functionality of the (Linux)BIOS (CPU, memory, peripheral
> > initialisation, etc) and GRUB (kernel loading, transfer of control
> > to kernel etc).

GRUB 2 has loaders, you can find them in loaders/.  For every OS a
separate loader is required.  I think the sourcecode is quite easy to
understand, but feel free to ask any question you have regarding the
code and its design.