Kevin O'Connor kevin@koconnor.net writes: ]> >>>>> On Tue, Jun 05, 2012 at 10:58:43AM +0200, Fred . wrote: ]> ]> [.] ]> ]> >> But does GPT disks even have a MBR? Isn't the GPT a replacement for ]> >> MBR? If the disk doesn't have any MBR, does the BIOS load the first ]> >> sector of GPT? ]> ]> To note: FreeBSD's version of "protective MBR" (pmbr.s) has the ]> support for GPT and will load the "big" bootloader from a GPT ]> partition of a specific type. ]> ]> > I'm not sure how I could be more clear on this. SeaBIOS cares nothing ]> > about the partition table. ]> ]> Not even about the 0x55 0xAA magic? ] ]SeaBIOS does check that the last two bytes of the first disk sector is ]0xaa55 before executing code there as a sanity test. ] ]> > No BIOS spec (that I'm aware of) requires the BIOS to care anything ]> > about the partition table. ]> ]> The problem is that the BIOS specs are currently being replaced ]> with the new UEFI ones, and UEFI boot sequence may be much more ]> complex (but, AIUI, even in the simplest case, it has to support ]> the MBR and GPT partition schemes, /and/ the FAT family of ]> filesystems.) ] ]UEFI is very complex. ] ]I've seen companies push UEFI as a requirement for >2Terabyte drives - ]but that's really not true. ] ]-Kevin
The UEFI related concern I am aware of is with booting. An OS setup DVD such as this one supports both standard 16-bit ElTorito boot as well as the UEFI adaption of ElTorito boot: http://mirror.symnds.com/distributions/fedora//releases/17/Live/x86_64/Fedor a-17-x86_64-Live-Desktop.iso
The standard ElTorito scheme results in loading the 16-bit code at image offset A2800-A2FFF to memory address 7C00 and executing it.
The UEFI adaptation of ElTorito results in mapping image offset 14800-A27FF as a FAT file system, and executing file EFI/BOOT/BOOTX64.efi in the 64-bit UEFI environment.
UEFI extends ElTorito by adding a new Platform ID value of 0xEF to designate an EFI entry in the boot catalog. Here is a summary of the ElTorito boot catalog for the fedora 17 image:
-----boot record volume descriptor at 8800----- volume descriptor: EL TORITO SPECIFICATION
-----boot catalog validation entry at 14000----- platform ID: 00=80x86 company :
-----boot catalog initial/default entry at 14020----- Boot indicator : 88=bootable Boot media type: 00=no emulation Load segment : 0000 Sector count : 0004 Load RBA : 00000145 (offset A2800)
-----section header at 14040----- Header indicator : 90=more headers follow Platform ID : EF=UEFI Sections following: 01 ID string : ""
-----section entry at 14060----- Boot indicator : 88=bootable Boot media type: 00=no emulation Load segment : 0000 Sector count : 0470 Load RBA : 00000029 (offset 14800)
-----section header at 14080----- Header indicator : 91=final header Platform ID : EF=UEFI Sections following: 01 ID string : ""
-----section entry at 140A0----- Boot indicator : 88=bootable Boot media type: 00=no emulation Load segment : 0000 Sector count : 08C0 Load RBA : 00000151 (offset A8800)
The EFI extensions to the El Torito specification are explained in UEFI specification version 2.3. For SeaBIOS to boot in UEFI mode would require adding a UEFI emulation layer. This is because 64-bit UEFI mode does not support INT 13, E820, etc.
The only possible boot concern for SeaBIOS is that some future operating system would drop support for 16-bit mode booting. Linus Torvald's comments about UEFI makes it pretty certain this won't happen with linux any time soon. Who knows what Microsoft will try to do.
I have heard the 2TB drive thing mentioned too. Obviously the method an operating system gets booted won't affect its ability to support a particular drive format. If someone really wants to boot a 2TB drive without partitioning, then I suppose UEFI could be a solution. I would think using a tiny FAT partition to hold boot files might be a workable solution for 16-bit booting. Or better yet use a small SSD drive for booting.
Thanks, Scott