grub-devel
[Top][All Lists]
Advanced

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

Understanding GRUB details


From: Bruce Dubbs
Subject: Understanding GRUB details
Date: Mon, 14 Dec 2009 17:28:32 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080722 SeaMonkey/1.1.11

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.












reply via email to

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