bug-grub
[Top][All Lists]
Advanced

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

Re: Details on blocklist in stage2/stage1_5


From: Thierry Laronde
Subject: Re: Details on blocklist in stage2/stage1_5
Date: Thu, 20 Jun 2002 19:59:43 +0200
User-agent: Mutt/1.2.5i

On Thu, Jun 20, 2002 at 07:48:02PM +0200, Thierry Laronde wrote:
> 
> OK, since I wrote a new version of the stage1 and I think Okuji is about
> to add it to the official source, here are some hints.
> 
> Things that may likely not change in a near future if the new stage1 is
> used (since size optimizations imply to use this very place):
> 
> Identification of the GRUB and boot abi version (MBR/first sector):
> 
> system_id: /* offset 03h */
>         .ascii  "GRUB " /* exactly 5 bytes */
>         .byte   COMPAT_VERSION  /* + 1 byte */
>         .byte   STAGE1_VERSION  /* + 1 byte */
>         .byte   0       /* +1 byte = 8 bytes */
>                               
> The COMPAT_VERSION identifies GRUB boot abi.
> STAGE1_VERSION can be ignored for that purpose: it is *only* the
> revision version of stage1.
> 
> In stage1 too is the crucial info about the first sector (of stage2 or
> stage1_5 that is in fact start.S) to load. It is, in the new version, at 
> offset:
> ---- in stage1/stage1.h
> /* The offset of STAGE2_SECTOR.  */
> #define STAGE1_STAGE2_SECTOR_OFFSET     0x32
> 
> ---- in stage1/stage1.S
> stage2_sector:
>         .long   1
>       
> These are unlikely to change too. For stage2/start.S which is the first
> sector of stage2/1_5 the structure MAY change but not in the very next
> days...
> 
> What I have in mind for the remaining parts (to have an easy way to
> identify what infos need to be changed) --- and that we haven't
> discussed so far --- is to create fake (I mean possibly unused) C
> headers files exposing the boot info structures, so that one can have a
> simple way to update tools having to manipulate this. This MAY be used
> too, internally by the GRUB, for booting OSes. So there will be a
> running time info (multiboot) and a compile time infos: the headers. The
> idea is to change for us the `boot' command so that filling up the
> correct structures for OSes will allow us to update more easily (having
> too perhaps a way to feed GRUB with this at running time via the
> `script' abilities (menu)).

One follow up. Reading stage1 (MBR/fist sector) leads one to the first
sector of the next stage (stage2 or stag1_5). One possibility could be
to put in start.S (the first sector of the next stage) a binary
description of the block list structure, since there is more room here.
This would complement the headers (always good to have it written
somewhere). It is --- for me --- unlikeky that the beginning of the
blocklist infos (end of the sector, growing backward) will change. But
the structure of the infos here may change (I have in mind some
simplifications) in the future.

Cheers,
-- 
Thierry Laronde (Alceste) <address@hidden>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



reply via email to

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