[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status grub2 port of grub-legasy map command

From: Vladimir 'phcoder' Serbinenko
Subject: Re: status grub2 port of grub-legasy map command
Date: Sun, 31 May 2009 18:00:14 +0200

2009/5/31 Javier Martín <address@hidden>:
> El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
>> 2009/5/31 Javier Martín <address@hidden>:
>> > El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
>> > escribió:
>> > Put it that way, I agree with your change. To the scrapper with
>> > parse_biosdisk then!
>> Sorry, I didn't mean to upset you. Here is a patch to do it
> You did not upset me at all! I'm sorry if I seemed rude or hostile. I
> truly meant to give you a go-ahead at scrapping that code.
Ok, thanks
>> Doing some tests I discovered that freedos MBR (but not the
>> bootsector) relies on %dl being preserved across int 0x13. In the
>> patch you can see additional hassle to preserve %dx.
> Do not do this. Some BIOS functions (like ah=08h) return data in dl.
> Clients should not expect data in registers to be preserved across
> interrupt calls. I don't know if there is something like a 8086/PC-BIOS
> ABI document that we can find to confirm the non-preservation of dl, but
> the FreeDOS MBR should be fixed then.
Thank you for pointing ah=8 function
AFAIK there is no normative reference. The source which was mainly
used for long years is helppc and it states following:
        - registers DS, BX, CX and DX are preserved
But now this reference is terribly outdated.
SeaBIOS preserves %dl too
According to wikipedia ah=8 is the only function which returns in %dl.
I will write an updated version which restores %dx only if ah!=8
> I managed to get the right %dl passed with the following procedure:
> let's say I want to boot FreeDOS on hd1, but I will drivemap it so that
> it will become hd0. Instead of doing this:
> root=(hd1,1)
> drivemap -s (hd0) (hd1)
> chainloader +1
> I do the following:
> root=(hd0)
> drivemap -s (hd0) (hd1)
> chainloader (hd1,1)+1
> This gets the right number into %dl (I have not checked multiboot), but
> I acknowledge that it's nothing more than a hack.
And it sets es:di (pointer to partition table entry) to incorrect value
> I cannot see a way for
> drivemap to access that data and modify it according to the mappings
> without breaking modularity with multiboot and chainloader
I think of something like having a function pointer in kernel
int (*grub_get_biosdisk) (grub_device_t dev) = grub_get_biosdisk_basic;
static int grub_get_biosdisk_basic (grub_device_t dev)
    if (! dev)
      return 0xff;
    if (! dev->disk)
      return 0xff;
    if (! dev->disk->dev)
      return 0xff;
    if (dev->disk->dev->id != GRUB_DISK_DEVICE_BIOSDISK_ID)
      return 0xff;
    return (int) dev->disk->id;
Which can be easily overridden by drivemap
But I don't really like this approach
> (and what
> about other loaders?).
AFAIR only multiboot and chainloader pass bios drive number to
payload. Other payloads are designed to use their own drivers
(multiboot is designed for both possibilities).
> Regarding grub2 using its own drivers, we have no reliable way of
> conclusively saying that (ata2)==(hd1), so we'd better say nothing at
> all and keep dl=ffh as we do currently.
I thought of introducing a variable "biosdrive" and doing something like
chainloader +1
Setting %dl to 0xff if drive can't be determined reliably and isn't
supplied by user is a good possibility. I'll do so.
> --
> -- Lazy, Oblivious, Recurrent Disaster -- Habbit
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Vladimir 'phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]