Re: About firmware facilities

[Brendan Trotter]

Hi,

On Tue, Sep 15, 2009 at 4:41 AM, Pavel Roskin <address@hidden> wrote:
> On Tue, 2009-09-15 at 04:27 +0930, Brendan Trotter wrote:
>> Hi,
>>
>> On Tue, Sep 15, 2009 at 1:02 AM, Robert Millan <address@hidden> wrote:
>> > Well, you have the freedom to disagree with anything we do and bring your
>> > customized GRUB to a different direction :-)
>> >
>> > Anyhow, my priority for GRUB is strong driver-based support.  We could 
>> > recruit
>> > someone to develop the framework in next year's GSoC (unless somebody steps
>> > in, of course).
>>
>> Why stop there?
>>
>> If proprietory ethernet ROMs aren't good enough, then what about
>> proprietory SCSI ROMs, and proprietory firmware/BIOS?
>
> We are already doing it.  There is functional ATA support, USB support
> is under development.

But, are you doing it for valid technical reasons?

> GRUB can serve as BIOS together with Coreboot.

I know. It'll break my code.

The multi-boot specification says "However, other machine state should
be left by the boot loader in normal working order, i.e. as
initialized by the bios (or DOS, if that's what the boot loader runs
from)."; although I seem to remember it saying words to the effect of
"the firmware should be left in a usable state".

Due to limitations in the original multi-boot specification my code
switches back to real mode and uses the BIOS to do memory detection,
do video mode detection, switch video modes and gather other
information. If GRUB is running on coreboot or UEFI I can't do this
(and can't work around the limitations any other way). Unless the
multi-boot specification is changed significantly (such that a
multi-boot compliant code needs no work-arounds, or at least so that
multi-boot compliant code can determine what sort of firmware there
was and use the firmware) then GRUB as a whole becomes useless to me.

The current draft (http://grub.enbug.org/MultibootDraft) is a small
step in the right direction; but it has changed much in 3 years.

>> Why are you worrying about such silly things when the multi-boot
>> specification (which actually is relevant) is still severely borked?
>
> Patches are welcome.

I'm not sure it's possible to write patches for a multi-boot compliant
boot loader without a specification that defines "multi-boot
compliant".


Cheers,

Brendan