From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Cc: linuxbios@openbios.org, Svante Signell <svante.signell@telia.com>
Subject: Re: GRUB vs LinuxBIOS question
Date: Thu, 29 Dec 2005 18:32:48 +0100 [thread overview]
Message-ID: <87bqyzn70f.fsf@xs4all.nl> (raw)
In-Reply-To: <20051229170421.GA21280@openbios.org> (Stefan Reinauer's message of "Thu, 29 Dec 2005 18:04:22 +0100")
Stefan Reinauer <stepan@openbios.org> writes:
Hi,
> * Svante Signell <svante.signell@telia.com> [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.
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.
> 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.
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.
--
Marco
prev parent reply other threads:[~2005-12-29 17:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1135872727.6254.11.camel@em2.my.own.domain>
2005-12-29 17:04 ` GRUB vs LinuxBIOS question Stefan Reinauer
2005-12-29 17:32 ` Marco Gerards [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bqyzn70f.fsf@xs4all.nl \
--to=mgerards@xs4all.nl \
--cc=grub-devel@gnu.org \
--cc=linuxbios@openbios.org \
--cc=svante.signell@telia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.