Re: About firmware facilities

[Vladimir 'phcoder' Serbinenko]

On Tue, Sep 15, 2009 at 1:23 AM, Brendan Trotter <address@hidden> wrote:
> Hi,
>
> On Tue, Sep 15, 2009 at 6:19 AM, Vladimir 'phcoder' Serbinenko
> <address@hidden> wrote:
>> On Mon, Sep 14, 2009 at 10:12 PM, Brendan Trotter <address@hidden> wrote:
>>> 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:
>>>> 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.
>
> Sounds like you need better firmware - Coreboot might be a good
> alternative. I assume GRUB is meant to be a boot loader though (rather
> than a project to rewrite every piece of dodgy software ever written).
>
Coreboot is a minimal firmware. It has no drivers
>>>> 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.
>
> So if the firmware is present, GRUB won't alter the state that the
> firmware left the hardware in (or if it does it'll restore all
> hardware to the default firmware state before starting the OS);
> including all devices that GRUB uses via. it's own device drivers
> (except for specific things mentioned in the multi-boot specification,
> like the A20 gate)?
>
No. Usuable means only that firmware isn't destroyed. Any device may
be in a different 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.
>>
>> 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.
>
> I've read the multi-boot specification. I've also read the code in
> GRUB-legacy that does memory detection, and I'm unwilling to allow my
> code to rely on it for "quality control" reasons. Without going into
> details, GRUB-legacy tends to do a "minimal" job and then expects the
> user to fix the problem if/when it goes wrong (but even then it only
> offers a "uppermem" command without providing a way for the user to
> specify a complete system memory map).
>
What is "minimal job" and "quality control"? We use standard
E820+(optionally)badram command. I've seen no OS do any more than
this.
>
> My code gives the user a choice of any video modes that are supported
> by the video card and my code (and doesn't allow them to choose video
> modes that aren't supported by my code), including double scanned
> modes (if supported by the video card) and a variety of refresh rates
> (if supported by the video card). It also uses the monitor's EDID
> information to try to prevent video modes that are supported by the
> video card but not supported by the monitor from being used. This is
> mostly automated, so that (for e.g.) the user can replace the monitor
> with another monitor that doesn't support the video mode that was
> previously used, and the software will find the best video mode that
> the new monitor does support without the user changing anything.
The mode listed in multiboot header is only suggested one. User or
bootloader may choose any other mode. But I agree that multiboot2
should have a way for better video mode suggesting.

> It'd be nice if other output methods were exposed to the OS too. For
> example, if GRUB is configured to use a serial terminal it'd be good
> if it told the OS details for the serial port, so that the OS can
> continue using the same serial terminal without resetting/restarting
> an established connection or requiring the user to configure it in 2
> separate places (in GRUB and in the OS).
I'll think about it
>
> The same would apply to internationalization - GRUB should tell the OS
> which language/locale it used, so that the OS can automatically use
> the same language as a default (especially for OS installation CDs).
Just add lang=$lang to multiboot line
>
> For memory detection, ACPI 3.0 allows the BIOS (" INT 15H, E820H") to
> return extended attributes - mostly only a volatile/non-volatile flag.
> This isn't in GRUB's information. ACPI 3.0 also allows the BIOS to
> return areas of the type "AddressRangeUnusable" (e.g. faulty RAM).
This is mostly unnecessary. Basically you need only to know if you can
use a memory range or not. The only useful additional code would be
ReclaimMemory
> If
> the BIOS reports that the area from 0x00100000 to 0x001FFFFF is
> faulty, then how is GRUB planning to handle that? My own code (if
> using it's own boot loaders rather than GRUB) can tolerate RAM
> failures anywhere in RAM except for about 64 KiB in low memory.
GRUB can't do this right now because it doesn't recieve badram info
soon enough. And even if it does most kernels expect first MiB to be
usable.
>
> While I'm on the subject, I also want a list of RAM areas that the
> boot loader has relied on. That way if a 24/7 server detects that any
> RAM that the boot loader relies on has become faulty it can warn the
> user that the computer may not be able to boot. Currently I assume
> that all multi-boot compliant boot loaders (including GRUB) rely on
> all RAM below 0x00100000, but it's a dodgy hack I'd rather avoid.
Such list is a blatant encapsulation breach. If you want such test,
add it to bootloader, not OS.
>
> In the memory map, GRUB should mark areas that it has used to pass
> information to the OS (e.g. the multi-boot information structure) as
> "multi-boot reclaimable" (in a similar way that ACPI uses the "ACPI
> reclaimable" type). This would make it easier for the OS to avoid
> overwriting this data before it attempts to read it.
This information is available with a simple loop over mbi. I would
rathjer avoid overcomplicating the standard because it increases a
chance of having "half-compliant" OSes and "half-compliant" booters.
> The area types
> need to be "architecture independent" types too (e.g. GRUB converts
> ACPI area types, UEFI area types, etc into "standard multi-boot area
> types").
It already is.
>
> The "Boot device" field in the multi-boot information structure should
> be improved to handle a variety of conditions; including if the disk
> was an emulated disk (e.g. "El Torito" emulating a hard drive). The
> BIOS drive number isn't much use (especially if the firmware is
> coreboot, UEFI, OpenFirmware, etc), and should be replaced with
> something that identifies the corresponding drive structure (this
> includes USB).
Boot device shouldn't be used at all. It was a mistake. Booter has no
good way to know how OS will see the device. You should pass this
parameter via commandline either as device name or UUID. You have
scripting to automate this
> If the boot device was ethernet then the "Boot device"
> field should contain a reference to a "network card information
> structure" that includes the ethernet card's MAC address (and any IP
> addresses, etc from DHCP, if applicable).
I already discussed this with Seth Goldberg but no time to write
multiboot ammendment yet.
>

> The "boot loader name" field is nice, but it needs a "boot loader
> version" field to go with it.
it's a part of name. This field is more for displaying anyway and OS
shouldn't do any checks based on it
> A "firmware type" field is also needed.
Can you respond in appropriate thread?
>
> The OS image also needs a different magic number to indicate that the
> OS image is designed for future versions of the multi-boot
> specification (rather than the old/current version). If the OS image
> uses the new magic number, then the OS image must also include an
> "version of the multi-boot specification that this image complies
> with" field. If the OS image indicates that it's intended for a newer
> version of the multi-boot specification than the boot loader complies
> with, then the boot loader refuses to boot and displays a "this boot
> loader needs to be upgraded" error. If the OS image has the old magic
> number, and if the firmware is "PC BIOS" then the boot loader should
> boot the old OS image. If the OS image has the old magic number, and
> if the firmware is not "PC BIOS" then the boot loader refuses to boot
> and displays a "this OS requires a PC BIOS" error message.
Already implemented through feature fields
>
> In a similar way, if the OS image has the old magic number and the
> boot loader is not running on 80x86 then the boot loader refuses to
> boot and displays an error message. If the OS image has the new magic
> number then it must also include a field that indicates which
> architecture the OS is intended for, and the boot loader must check
> this field and display a "this OS is intended for a different
> architecture" error message (and refuse to boot) if it's wrong.
>
multiboot1 and multiboot2 have different magics
>>> 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
>
> By "multi-CPU" you mean different architectures, rather than
> SMT/SMP/NUMA support?
I mean ARM, PPC, MIPS and so on.
>
>>>>> 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
>
> That's the old version of the multi-boot specification (for
> GRUB_legacy). I'm looking forward to a new version of the multi-boot
> specification (for GRUB 2) that is designed to support different
> architectures, different types of firmware on the same architecture,
> etc; and hopefully other improvements.
>
multiboot1 ISN'T depreceated and grub2 supports multiboot1
>
> 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