On Tue, Jun 05, 2012 at 10:58:43AM +0200, Fred . wrote:
On Tue, Jun 5, 2012 at 5:21 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Mon, Jun 04, 2012 at 07:11:30PM -0700, Ralf A. Quint wrote:
At 03:36 PM 6/4/2012, Kevin O'Connor wrote:
On Mon, Jun 04, 2012 at 03:33:05PM +0200, Fred . wrote:
http://mjg59.dreamwidth.org/8035.html
Does SeaBIOS support GPT disk labels? Does SeaBIOS understand GPT disk labels? Is it aware of GPT?
This is a common misunderstanding of the BIOS. The BIOS doesn't do anything with partition tables at all (at least according to the available specs). Thus, the BIOS doesn't care if it's a legacy partition table or a GPT partition table.
Excuse me, but isn't it the BIOS that after POST is initiating the boot process from the active partition?
Not quite. The BIOS loads the first sector of the hard drive (ie, the MBR) into memory and runs the code found there. It cares nothing about the partition table. It's quite common for the executable code in that first sector to analyze the partition table, load yet other code, and then jump to that code - but that activity is outside the BIOS and is easily upgradable.
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?
I'm not sure how I could be more clear on this. SeaBIOS cares nothing about the partition table. No BIOS spec (that I'm aware of) requires the BIOS to care anything about the partition table. The BIOS loads the first sector of the hard drive into memory and executes the code found there. GPT partitioned disks do arrange to be able to place boot code in the first sector of the hard drive.
The only fundamental limit SeaBIOS has on drive size is a 64bit sector count - this allows for up to 134 million terabytes of disk space (assuming a 512 byte sector). But, even this isn't really a limit - one just needs to be able to locate their bootloader in the first 134million terabytes.
-Kevin
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?
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.)
Check, e. g., [1].
[1] http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
The BIOS loads the first sector of the hard drive into memory and executes the code found there. GPT partitioned disks do arrange to be able to place boot code in the first sector of the hard drive.
[…]
On Tue, Jun 05, 2012 at 11:39:35PM +0700, Ivan Shmakov wrote:
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
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
-
Ivan Shmakov -
Kevin O'Connor -
Scott Duplichan