Understanding GRUB details

Understanding GRUB details

[Bruce Dubbs]

In order to properly document GRUB, I have been reviewing some of the 
code at a rather detailed level.  My efforts are directed at developing 
an intimate level of understanding as a prerequisite for the 
documentation effort.  I fully understand that many of the details below 
are not appropriate for grub.texi, but they may be appropriate for other 
venues such as a wiki.

The GRUB code is fairly complex.  Below is a summary of the GRUB boot 
process as I understand it from the code.  I would appreciate any 
corrections or problems you may observe in the description below.

Thanks.

   -- Bruce

My analysis so far assumes a i386 pc platform booting from a generic 
disk drive and booting linux.


Booting the MBR:  boot.img (architecture specific)

   The PC BIOS determines the boot device and loads the first physical 
sector of that device, commonly known as the Master Boot Record (MBR) 
into memory.  The memory location is an absolute physical address of 
0x07C000, which is one 512-byte sector below the 1st 32K memory 
boundary.  I think, but cannot confirm, that this memory location is for 
historical reasons only.

   The BIOS passes the disk drive being booted via the DL register. 
This value would normally be 0x80 for the first hard drive and is 
equivalent to GRUB's (hd0), but grub-setup may over-ride it and set it 
to 0x80.

   The MBR code is generated from GRUB's /boot/i386/pc/boot.S source 
code.  This is installed by grub-setup (grub-setup.c), but copies any 
BIOS Parameter Block (BPB) and Partition Table from the existing MBR 
code before overwriting the sector.

   The MBR functions by reading exactly one sector using the BIOS INT 
13h, function 042h, from the second physical disk sector (address 1) on 
the boot disk to memory location 0x70000.  Then the memory at 0x70000 is 
copied to 0x80000 and the code at 0x80000 is then executed.

----------------------

Second stage: core.img

   For historical reasons, disk partitions on the pc are considered to 
be aligned on track boundaries where the number of sectors per track is 
63.  The first partition is at track 1 reserving track 0 for the boot 
process.  The MBR is sector 0 and sectors 1 to 62 can then be used for 
other boot code like core.img.  Therefore the maximum size of core.img 
is 31744 bytes (31K).  The core.img is binary code partially compressed 
with the LZMA algorithm.

   core.img is created by grub-mkimage (usually via grub-install) from 
kernel.img and other system specific parameters.  The default i386 
built-in modules and dependencies are:
   biosdisk.mod
   ata.mod (pci.mod, scsi.mod)
   file system   :  determined by grub-probe (e.g. ext2.mod, fshelp.mod)
   partition type: determined by grub-probe( e.g. part_msdos.mod)

core.img is installed into the first logical track (sectors 1 to 63) of 
the disk drive by grub-setup.

   The first sector of pc core.img is generated from the 
boot/i386/pc/diskboot.S file.  Note:  There appears to be a comment
error in this file.  It says it starts at location 0x02000, but boot.S 
and conf/i386-pc.rmk indicates it is at 0x80000.

   After the first sector of core.image is loaded by the MBR, it loads 
the rest of itself into memory using BIOS INT 13h calls.  At a 
relatively early point, the code transitions from the CPU's real mode to 
protected mode to effectively remove memory limits, loads default 
modules from the boot drive, reads the GRUB configuration file and 
proceeds according to the instructions there or from the command line.

   The final task then is to load the kernel image or the next 
chainloader disk sector and transfer execution to that code.  At that 
point GRUB considers the boot process complete.

Re: Understanding GRUB details

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4716 bytes --]

Bruce Dubbs wrote:
> In order to properly document GRUB, I have been reviewing some of the
> code at a rather detailed level.  My efforts are directed at
> developing an intimate level of understanding as a prerequisite for
> the documentation effort.  I fully understand that many of the details
> below are not appropriate for grub.texi, but they may be appropriate
> for other venues such as a wiki.
>
> The GRUB code is fairly complex.  Below is a summary of the GRUB boot
> process as I understand it from the code.  I would appreciate any
> corrections or problems you may observe in the description below.
>
> Thanks.
>
>   -- Bruce
>
> My analysis so far assumes a i386 pc platform booting from a generic
> disk drive and booting linux.
>
>
> Booting the MBR:  boot.img (architecture specific)
>
>   The PC BIOS determines the boot device and loads the first physical
> sector of that device, commonly known as the Master Boot Record (MBR)
> into memory.  The memory location is an absolute physical address of
> 0x07C000, which is one 512-byte sector below the 1st 32K memory
> boundary.  I think, but cannot confirm, that this memory location is
> for historical reasons only.
0:0x7c00 (one zero too much and you have to prefix it with segment in
real mode)
>
>   The BIOS passes the disk drive being booted via the DL register.
> This value would normally be 0x80 for the first hard drive and is
> equivalent to GRUB's (hd0), but grub-setup may over-ride it and set it
> to 0x80.
Some buggy BIOSes pass wrong %dl
>
>   The MBR code is generated from GRUB's /boot/i386/pc/boot.S source
> code.  This is installed by grub-setup (grub-setup.c), but copies any
> BIOS Parameter Block (BPB) and Partition Table from the existing MBR
> code before overwriting the sector.
>
Correct
>   The MBR functions by reading exactly one sector using the BIOS INT
> 13h, function 042h, from the second physical disk sector (address 1)
> on the boot disk to memory location 0x70000.  Then the memory at
> 0x70000 is copied to 0x80000 and the code at 0x80000 is then executed.
>
42h = LBA. boot sector usually uses LBA but can fallback to CHS.
Addresses are wrong.
> ----------------------
>
> Second stage: core.img
>
>   For historical reasons, disk partitions on the pc are considered to
> be aligned on track boundaries where the number of sectors per track
> is 63.  The first partition is at track 1 reserving track 0 for the
> boot process.  The MBR is sector 0 and sectors 1 to 62 can then be
> used for other boot code like core.img.  Therefore the maximum size of
> core.img is 31744 bytes (31K).  The core.img is binary code partially
> compressed with the LZMA algorithm.
Correct
>
>   core.img is created by grub-mkimage (usually via grub-install) from
> kernel.img and other system specific parameters.
Modules, not parameters
>   The default i386 built-in modules and dependencies are:
>   biosdisk.mod
>   ata.mod (pci.mod, scsi.mod)
Either of them, never 2 together
>   file system   :  determined by grub-probe (e.g. ext2.mod, fshelp.mod)
>   partition type: determined by grub-probe( e.g. part_msdos.mod)
>
Sometimes also lvm and/or raid.
> core.img is installed into the first logical track (sectors 1 to 63)
> of the disk drive by grub-setup.
>
Or on BIOS Boot Paratition on GPT. Or *sigh* blocklists for
backward-compatibility (blocklists are unreliable)
>   The first sector of pc core.img is generated from the
> boot/i386/pc/diskboot.S file.  Note:  There appears to be a comment
> error in this file.  It says it starts at location 0x02000, but boot.S
> and conf/i386-pc.rmk indicates it is at 0x80000.
>
It's on 0:0x8200
>   After the first sector of core.image is loaded by the MBR, it loads
> the rest of itself into memory using BIOS INT 13h calls.  At a
> relatively early point, the code transitions from the CPU's real mode
> to protected mode to effectively remove memory limits, 
Enables gate A20 too
> loads default modules from the boot drive, 
First it loads embeded modules, and only then proceeds to load
normal.mod and its dependencies
> reads the GRUB configuration file and proceeds according to the
> instructions there or from the command line.
>
>   The final task then is to load the kernel image or the next
> chainloader disk sector and transfer execution to that code.  At that
> point GRUB considers the boot process complete.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Understanding GRUB details

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Bruce Dubbs wrote:
>> In order to properly document GRUB, I have been reviewing some of the
>> code at a rather detailed level.  My efforts are directed at
>> developing an intimate level of understanding as a prerequisite for
>> the documentation effort.  I fully understand that many of the details
>> below are not appropriate for grub.texi, but they may be appropriate
>> for other venues such as a wiki.

Thanks for the feedback.  It helps.

   -- Bruce

Re: Understanding GRUB details

[Robert Millan]

On Mon, Dec 14, 2009 at 05:28:32PM -0600, Bruce Dubbs wrote:
> into memory.  The memory location is an absolute physical address of  
> 0x07C000, which is one 512-byte sector below the 1st 32K memory  
> boundary.  I think, but cannot confirm, that this memory location is for  
> historical reasons only.

Yes.

>   The BIOS passes the disk drive being booted via the DL register. This 
> value would normally be 0x80 for the first hard drive and is equivalent 
> to GRUB's (hd0), but grub-setup may over-ride it and set it to 0x80.

This sounds wrong.  I think it could be doing this, but only in desperate
situations (e.g. %dl was obviously wrong).

The basic problem is that we can't predict BIOS disk order reliably.  This
is a recurrent issue throurough different parts of GRUB.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi