1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
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.
|
