Re: Understanding GRUB details

[Vladimir 'φ-coder/phcoder' Serbinenko]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


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

signature.asc
Description: OpenPGP digital signature