[syslinux] [PATCH] chain.c32: add support for loading GRUB stage2

Paul Bolle pebolle at tiscali.nl
Mon Jun 28 04:57:48 PDT 2010


On Mon, 2010-06-28 at 03:03 -0700, Gert Hulselmans wrote:
> I added support for passing the install_partition to chain.c32.
> 
> It is already committed (and available in Syslinux-4.00-pe64.
> 
> From 4be5c7c1de0cdfdd0c5f42c116e240112a9af8cc Mon Sep 17 00:00:00 2001
> From: Gert Hulselmans <gerth at zytor.com>
> Date: Mon, 28 Jun 2010 03:11:48 +0200
> Subject: [PATCH] chain.c32: pass partition number to stage2 of Grub Legacy
> 
> Grub Legacy stage2 will read the install_partition variable from
> memory address 0x8208.
> We only need to change the value at 0x820a to the correct partition
> number:
>   -1:   whole drive (default)
>   0-3:  primary partitions
>   4-*:  logical partitions
> 
> Signed-off-by: Gert Hulselmans <gerth at zytor.com>
> ---
>  com32/modules/chain.c |   13 ++++++++-----
>  1 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/com32/modules/chain.c b/com32/modules/chain.c
> index a76d275..4f5baf1 100644
> --- a/com32/modules/chain.c
> +++ b/com32/modules/chain.c
[...]
> @@ -1585,10 +1585,13 @@ int main(int argc, char *argv[])
>  	if (opt.grub) {
>  	    regs.ip = 0x200;	/* jump 0x200 bytes into the loadfile */
> 
> -	    /* 0xffffff00 seems to be GRUB ways to record that it's
> -	       "root" is the whole disk (and not a partition). */
> -	    *(uint32_t *) ((unsigned char *)data[ndata].data + 0x208) =
> -		0xffffff00ul;
> +	    /* GRUB's stage2 wants the partition number in the install_partition
> +	     * variable, located at memory address 0x8208.
> +	     * We only need to change the value of memory address 0x820a too:
> +	     *   -1:   whole drive (default)
> +	     *   0-3:  primary partitions
> +	     *   4-*:  logical partitions */

Wouldn't it be better to also document that:
- 0x802b is ignored by GRUB;
- 0x8029 represents BSD disk slices (which SYSLINUX doesn't seem to care
about);
- 0x8028 is also ignored by GRUB?

(Maybe it should even be mentioned that these four bytes seem to be
related to the boot_device field in the (current) multiboot
specification.)

All of this is stuff that is neither obvious nor easily discovered. 

> +	    ((uint8_t*) data[ndata].data)[0x20a] = (uint8_t)(whichpart - 1);

0) This works OK if whichpart is set to non-zero, eg with:
    chain boot 2 grub=stage2

This fails however (ie, 0xff/"whole drive" will be used) if whichpart
isn't yet set, eg with:
    chain boot grub=stage2

1) Isn't it better to set [0x209] to 0xff here (ie, "no BSD disk slices
are used")?

>  	}
> 
>  	ndata++;

Paul




More information about the Syslinux mailing list