path: root/doc
diff options
authorH. Peter Anvin <hpa@zytor.com>2008-05-13 18:30:20 -0700
committerH. Peter Anvin <hpa@zytor.com>2008-05-13 18:30:20 -0700
commit1bd7c31844a7b946c5d2d85a21e913fa81460930 (patch)
treeb13d5a208672d9d074962b64e6264cfe6a328d27 /doc
parente9a648998ff7347442db21421ac279e05d030b5f (diff)
Document GPT boot protocol; add !GPT signature3.6x
Document the GPT boot protocol; add additional assurance by requiring that EAX contains "!GPT" for the GPT information to be valid.
Diffstat (limited to 'doc')
1 files changed, 92 insertions, 0 deletions
diff --git a/doc/gpt.txt b/doc/gpt.txt
new file mode 100644
index 00000000..42a4da18
--- /dev/null
+++ b/doc/gpt.txt
@@ -0,0 +1,92 @@
+ GPT boot protocol
+There is no official MBR-to-partition handover protocol defined for
+booting from disks partitioned using GPT partition tables with
+BIOS-style firmware. This is because the GPT partition format comes
+from the EFI spec, which thinks the universe is all going to be EFI.
+There are thus two alternatives: hybrid booting, and defining a new
+ *** Hybrid booting ***
+Hybrid booting uses a standard MBR, and has bootable ("active")
+partitions present, as partitions, in the GPT PMBR sector. This means
+the PMBR, instead of containing only one "protective" partition (type
+EE), may contain up to three partitions: a protective partition (EE)
+*before* the active partition, the active partition, and a protective
+partition (EE) *after* the active partition. The active partition is
+limited to the first 2^32 sectors (2 TB) of the disk.
+All partitions, including the active partition, should have GPT
+partition entries. Thus, changing which partition is active does NOT
+change the GPT partition table.
+This is the only known way to boot Microsoft operating systems from a
+GPT disk with BIOS firmware.
+ *** New protocol ***
+This defines an alternative (experimental) booting protocol for GPT
+partitions with BIOS firmware. It maintains backwards compatibility
+to the extent possible. It is implemented by the file mbr/gptmbr.bin.
+ -> The PMBR
+The PMBR (the first 512-byte sector of the disk) is divided up as
+ Offset Size Contents
+ ---------------------------------------------------------
+ 0 424 PMBR boot code
+ 424 16 GUID of the boot partition
+ 440 4 MBR-compatible disk ID
+ 444 2 Magic number: 1D 9A
+ 446 16 PMBR protective entry
+ 462 48 PMBR null entries
+ 510 2 Boot signature: 55 AA
+To change the bootable partition, verify that the magic number is
+present (to avoid corrupting software not compatible with this
+specification) and enter the GUID of the boot partition at offset
+424. It might be wise to verify that the data already there is a
+valid partition GUID already, or at least warn the user if that is not
+the case.
+ -> The handover protocol
+The PMBR boot code loads the first sector of the bootable partition,
+and passes in DL=<disk number>, ES:DI=<pointer to $PnP>, sets EAX to
+0x54504721 ("!GPT") and points DS:SI to a structure of the following
+ Offset Size Contents
+ ---------------------------------------------------------
+ 0 1 0x80 (this is a bootable partition)
+ 1 3 CHS of partition (using INT 13h geometry)
+ 4 1 0xEE (partition type: EFI data partition)
+ 5 3 CHS of partition end
+ 8 4 Partition start LBA
+ 12 4 Partition end LBA
+ 16 varies GPT partition entry
+The CHS information is optional; gptmbr.bin currently does *NOT*
+calculate them, and just leaves them as zero.
+Bytes 0-15 matches the standard MBR handover (DS:SI points to the
+partition entry), except that the information is provided
+synthetically. The MBR-compatible fields are directly usable if they
+are < 2 TB, otherwise these fields should contain 0xFFFFFFFF and the
+OS will need to understand the GPT partition entry which follows the
+MBR one. The "!GPT" magic number in EAX and the 0xEE partition type
+also informs the OS that the GPT partition information is present.
+Currently, this is compatible with Syslinux as long as the Syslinux
+partition is < 2 TB; this probably will be improved in a future