diff options
Diffstat (limited to 'doc/gpt.txt')
| -rw-r--r-- | doc/gpt.txt | 92 |
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. +Sigh. + +There are thus two alternatives: hybrid booting, and defining a new +protocol. + + *** 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 +follows: + + 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 +form: + + 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 +version. + + + + |