From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NKKLM-0006LB-M0 for mharc-grub-devel@gnu.org; Mon, 14 Dec 2009 18:28:44 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKKLL-0006Kx-9q for grub-devel@gnu.org; Mon, 14 Dec 2009 18:28:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKKLF-0006Ju-Nx for grub-devel@gnu.org; Mon, 14 Dec 2009 18:28:43 -0500 Received: from [199.232.76.173] (port=39488 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKKLF-0006Jq-Kh for grub-devel@gnu.org; Mon, 14 Dec 2009 18:28:37 -0500 Received: from mail-yw0-f202.google.com ([209.85.211.202]:61483) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKKLF-00007s-2B for grub-devel@gnu.org; Mon, 14 Dec 2009 18:28:37 -0500 Received: by ywh40 with SMTP id 40so3537265ywh.26 for ; Mon, 14 Dec 2009 15:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=hhmK/W9qLYC+R2dvBBreAE+f5Nb/yCfrdXuITpdq+ho=; b=Cd/Te9epK8UYApD6LgnOrBju/w8W+YvqRobmi9zQ9+d0RUnE5OmHZ1gSYbcrJnNPbz 9IOGG6Sv+zXoOIoCtbXGU4agt1fSQ0yOMdF3cN4Fart6np/fF7e2K5ztZt0fu7dAj0UU 4vG6DD63yMrCUbzIaD5pktStOcLSFpaqr50tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=p8fmBSAF6XM9ri7vWatzw+if3MqZE7D7L/QTI60vRQFcav26YuysW7CuXJdJHM5zrL xWD9X3192nxKyzA0vSOqDHmTGhrD7DTjgLI7umNIlvkx1REftWHRbEPb6I0RMVdeS9G7 PK0JYo8OHOVC2A4LC6TSxhyhEY/VdmUApyRbU= Received: by 10.101.194.26 with SMTP id w26mr7902121anp.188.1260833313802; Mon, 14 Dec 2009 15:28:33 -0800 (PST) Received: from ?192.168.0.75? (cpe-66-69-97-231.satx.res.rr.com [66.69.97.231]) by mx.google.com with ESMTPS id 8sm2080517yxb.7.2009.12.14.15.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 15:28:33 -0800 (PST) Message-ID: <4B26CA20.9090005@gmail.com> Date: Mon, 14 Dec 2009 17:28:32 -0600 From: Bruce Dubbs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080722 SeaMonkey/1.1.11 MIME-Version: 1.0 To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Understanding GRUB details X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 23:28:43 -0000 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.