Hi!
Rudolf reported that GRUB doesn't start on LBv2 because it attempts to find the memory map table at 0x500, and it isn't always there. For him it is at 0x530, but looking at the code it seems not to be hardcoded, but instead right after a GDT that does live at 0x500. See:
http://grub.enbug.org/LinuxBIOS
Is there a spec on something on what should payloads do about this? Probe 0x500 and 0x530 or ... ?
TIA
* Robert Millan rmh@aybabtu.com [071106 21:28]:
Hi!
Rudolf reported that GRUB doesn't start on LBv2 because it attempts to find the memory map table at 0x500, and it isn't always there. For him it is at 0x530, but looking at the code it seems not to be hardcoded, but instead right after a GDT that does live at 0x500. See:
http://grub.enbug.org/LinuxBIOS
Is there a spec on something on what should payloads do about this? Probe 0x500 and 0x530 or ... ?
See LinuxBIOSv2/util/lxbios/lbtable.c - The table can be anywhere in (low?) memory, at a 16byte aligned memory address. It can be probed by looking for the LBIO signature and the checksum.
v2 may use different places for the LB table, while v3 always puts it at 0x500 so far. This is not gonna stay like that, though, as we might want to enhance bios compatibility by filling the EBDA at 0x500 (after the BDA at 0x400) at some point.
Stefan
On Wed, Nov 07, 2007 at 12:55:25AM +0100, Stefan Reinauer wrote:
bios compatibility
I would like any BIOS compatibility to be opt-in, and to be uninteresting because of new shinyness offered by LB and understood by all. :)
//Peter
On 07/11/07 01:12 +0100, Peter Stuge wrote:
On Wed, Nov 07, 2007 at 12:55:25AM +0100, Stefan Reinauer wrote:
bios compatibility
I would like any BIOS compatibility to be opt-in, and to be uninteresting because of new shinyness offered by LB and understood by all. :)
Except of course, the e820 table parser in the kernel... :)
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Tue, Nov 06, 2007 at 05:19:31PM -0700, Jordan Crouse wrote:
I would like any BIOS compatibility to be opt-in, and to be uninteresting because of new shinyness offered by LB and understood by all. :)
Except of course, the e820 table parser in the kernel... :)
Not neccessarily. Only if that really is a plenty good interface for the task. And maybe not even then, if there are enough other things that shall be passed to the payload.
What is the status of the OFW device tree parser in x86 Linux?
Do we still want to go with that or roll our own LB->payload interface?
Yes - we are re-inventing the wheel, but maybe we can improve it.
//Peter
On 07/11/07 01:54 +0100, Peter Stuge wrote:
On Tue, Nov 06, 2007 at 05:19:31PM -0700, Jordan Crouse wrote:
I would like any BIOS compatibility to be opt-in, and to be uninteresting because of new shinyness offered by LB and understood by all. :)
Except of course, the e820 table parser in the kernel... :)
Not neccessarily. Only if that really is a plenty good interface for the task. And maybe not even then, if there are enough other things that shall be passed to the payload.
What is the status of the OFW device tree parser in x86 Linux?
Its in the OLPC tree - I don't know if its made it all the way up stream yet - there was unpleasantness last year some time when they tried to push it, I think that stalled then.
Do we still want to go with that or roll our own LB->payload interface?
OFW device tree gets my vote.
Jordan
-
Jordan Crouse -
Peter Stuge -
Robert Millan -
Stefan Reinauer