Re: About firmware facilities

[Vladimir 'phcoder' Serbinenko]

On Mon, Sep 14, 2009 at 10:12 PM, Brendan Trotter <address@hidden> wrote:
> 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?
>
Yes. I have a borked firmware right on this laptop.
>> 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".
>
Firmware if present is left in usable state. However it may simply not
be present.
> 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.

Have you actually read the multiboot specification? Booter passes info
about memory and video mode in mbi (video for multiboot isn't
implemented yet). If you need firmware for basic bootup you're clearly
doing something wrong and are firmware-dependent. Of course it's your
freedom to make suboptimal software.
> 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.
Just say in clean text what changes you need so we can discuss it.
Don't expect us to understand the statement "your standard is borked,
change it".
>
> The current draft (http://grub.enbug.org/MultibootDraft) is a small
> step in the right direction; but it has changed much in 3 years.
>
It mainly introduces multi-CPU and another MBI format compared to multiboot1
>>> 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".
>
Read it here: http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
>
> Cheers,
>
> Brendan
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git