OSDev.org

Lately I become interested in UEFI and GPT. Unluckily my PC doesn't provide UEFI even if it's just two years old. Anyway I would like to write a bootloader for GPT on BIOS-based systems.
The BIOS would still jump to code in LBA 0 of the HD, not being aware of GPT.

Once we had reserved sectors, where we had as much space as needed to put boot code. However I didn't notice anything like reserved sectors in GPT. I would like to read an executable (binary or elf) from the EFI System Partition (FAT32 like) and jump to it. Quite too much for 448 bytes.

So my question is: where do I put booting code when using the GPT scheme?
As far as I read on wikipedia and the UEFI 2.3 specification the GPT partition table is on the LBA sector following the GPT header, which is on LBA 1. So the partition table should always be on LBA 2. However the table contains a "PartitionEntryLBA", which is usually set to 2.

If I set this to, say, 30, I would obtain 28 unused sectors. But is this legal? Or will OSs assume the table on LBA 2?

Thanks.

It seems to me that you don't want to provide EFI service, just want to use GPT partitioning scheme. So you should have GPT (hybrid MBR) boot loader and perhaps GPT-oriented stage 1 boot loader (however specific stage 1 is not necessary now because modern BIOSes have problems with 64-bit LBA addressing in EDD service functions; you can't use full-wide 64-bit LBA addresses anyway).

To boot stage 1 boot loader GPT boot loader checks boot flag for each partition in GPT. It will be good if GPT boot loader will provide interface described in EDD Spec. 440 bytes are enough for GPT boot loader. You can put additional code into stage 1, and/or into stage 2.

So you want to boot from a GPT disk on a legacy BIOS machines. Don't relocate GPT, keep PartitionEntryLBA 2 (maybe not necessairly, but many tool doesn't handle this properly). Instead do this:
1. write this code to the MBR mbr_gpt
2. create a BIOS legacy boot partition
3. put your stage2 loader (elf loader/parser) or grub2 on that partition

@egos:

To boot stage 1 boot loader GPT boot loader checks boot flag for each partition in GPT.

No. GPT entries do not have such a flag. It's an M$ extension, only handled by M$ tools. Read the doc, UEFI has a different mechanism to choose OS to boot (a special nvram variable that records the selected OS' loader's full path, and if not found, fallbacks to FS0:/EFI/BOOT/X64BOOT.EFI). It worth mentioning that this loader can be a boot manager app, that properly handles M$' boot flag.

turdus wrote:No. GPT entries do not have such a flag. It's an M$ extension, only handled by M$ tools. Read the doc, UEFI has a different mechanism to choose OS to boot (a special nvram variable that records the selected OS' loader's full path, and if not found, fallbacks to FS0:/EFI/BOOT/X64BOOT.EFI). It worth mentioning that this loader can be a boot manager app, that properly handles M$' boot flag.

They have.

UEFI Spec.:

Bit 2 - Legacy BIOS Bootable - This bit is set aside by this specification to let systems with traditional PC-AT BIOS firmware implementations inform certain limited, special-purpose software running on these systems that a GPT partition may be bootable.

EDD Spec.:

Hybrid MBR boot code performs the following steps:
...
7) search the GPT Partition Entry Array for a partition with the Legacy BIOS Bootable bit set to one in the Attributes field. The code may also check for a special value in the Partition Type GUID field when selecting the partition;

We talk about BIOS booting, not EFI booting. BIOS boot partition can be used as alternative to partition that is marked with boot flag.

My copy does not contain it, but it's a bit out of date I have to admit. I'll get a fresh one.
Nevertheless, UEFI does not specify PMBR code, so there's no point to define any legacy flags. It will load only one partition (without fs!) as stage2, that's all. And how stage2 interpret GPT to find a valid system volume is a different story. What's most common, they change a bit fs type uuid (or use a totally different uuid), see http://en.wikipedia.org/wiki/GUID_Parti ... type_GUIDs

Note: marking a partition for booting is independent of how it's loaded. Separate legacy flags and other mechanisms therefore could be inconsistent, which is bad.

I've written a PMBR that will determine if it's actually a real MBR or GPT, if MBR load the active partition, or if GPT parse it and load the VBR for the EFI system partition (or the "Hah!IdontNeedEFI" partition). I'm now in the process of writing the stage1 that then loads the stage2 and enters that. Really it's just like using MBR, but with a little extra work to find the partition if the disk is GPT instead. Unfortunately ATM it does no validation of the GPT so if it gets corrupted it won't be able to deal with it. Also last I checked GParted doesn't understand that "reserved" means "don't zero it out, leave it the hell alone" so be careful of that if you use GParted.

Firestryke31 wrote:... parse it and load the VBR for the EFI system partition (or the "Hah!IdontNeedEFI" partition).

And what detection priority between EFI system partition and BIOS boot partition do you use? Who is first that wins!

I'm now in the process of writing the stage1 that then loads the stage2 and enters that. Really it's just like using MBR, but with a little extra work to find the partition if the disk is GPT instead.

But stage 1 could be booted using other boot indication that it use. There are special mechanisms to detect the partition where stage 1 was booted from. GPT boot loader can provide interface described in EDD Spec. for that detection.

egos wrote:

Firestryke31 wrote:... parse it and load the VBR for the EFI system partition (or the "Hah!IdontNeedEFI" partition).

And what detection priority between EFI system partition and BIOS boot partition do you use? Who is first that wins!

ATM yes, first encountered is the one that boots. If I can trim enough out I'd like to be able to give priority to the EFI system partition in the future.

I'm now in the process of writing the stage1 that then loads the stage2 and enters that. Really it's just like using MBR, but with a little extra work to find the partition if the disk is GPT instead.

But stage 1 could be booted using other boot indication that it use. There are special mechanisms to detect the partition where stage 1 was booted from. GPT boot loader can provide interface described in EDD Spec. for that detection.

The EFI system partition is for all practical purposes FAT32. The FAT spec defines a field that more or less indicates the beginning of the partition on the disk (granted, it's only a 32-bit LBA). My stage1 uses this field to determine where it is, allowing it to be used as either MBR, or GPT without giving diddly squat about who loaded it (it could be the BIOS for all it cares, since my (p)MBR loads the VBR to 0000:7C00 like normal. For a while it even pointed DS:SI to the partition entry that booted whether MBR or GPT, but I had to trim that feature to fit everything in (mainly because the file systems I've worked with so far have a field in the header saying where on the disk it is, so the DS:SI pointer was redundant).

Firestryke31 wrote:ATM yes, first encountered is the one that boots. If I can trim enough out I'd like to be able to give priority to the EFI system partition in the future.

I prefer other technique. Sample GUID is placed at fixed location in PMBR. And GPT boot loader does following steps: if sample GUID is a null GUID then set some flag else clean it; if some flag is set then check partition entry by boot flag else check it by sample GUID. This technique allows to use any type of boot partition and detect it by GUID or by boot flag.

The EFI system partition is for all practical purposes FAT32. The FAT spec defines a field that more or less indicates the beginning of the partition on the disk (granted, it's only a 32-bit LBA). My stage1 uses this field to determine where it is, allowing it to be used as either MBR, or GPT without giving diddly squat about who loaded it (it could be the BIOS for all it cares, since my (p)MBR loads the VBR to 0000:7C00 like normal. For a while it even pointed DS:SI to the partition entry that booted whether MBR or GPT, but I had to trim that feature to fit everything in (mainly because the file systems I've worked with so far have a field in the header saying where on the disk it is, so the DS:SI pointer was redundant).

I use HiddenSectors field in stage 1 too. However, my MBR boot loaders provide DS:SI pointer. Besides, EDD Spec. describes extension for the structure passed by this pointer. Extension fields hold GPT partition entry and its length.

egos wrote:I prefer other technique. Sample GUID is placed at fixed location in PMBR. And GPT boot loader does following steps: if sample GUID is a null GUID then set some flag else clean it; if some flag is set then check partition entry by boot flag else check it by sample GUID. This technique allows to use any type of boot partition and detect it by GUID or by boot flag.

I want to give the EFI partition priority because I'm trying to write an EFI emulator, so I want the pMBR to go for it first. The ability to go for other types was just a goodie that I don't care about. I also have it set up to be able to boot as a regular MBR disk, which ate up a bunch of the space in the loader. My to do list in order of personal priority is ATM: Optimize for size, EFI system partition priority for both MBR and GPT types, DS:SI passing for playing nice with other bootloaders, and validate GPT CRC32 and load backup GPT if corrupted.

Really I could dump the Hah!IdontneedEFI partition support and feedback output (i.e. "xyz GPT booting" or "xyz MBR gave up") and free up a bunch of space for EFI-specific support, but I wanted to be relatively environment-agnostic (i.e. it doesn't care whether the VBR it's loading is mine, MS's, Linux's, yo mama's, etc.; it just loads to 7C00 and goes). I also didn't want to introduce a bunch of tools to support using my bootloader, since knowing OSS they'd write their own version and screw something up so I can't add features without breaking the way they do things and then everybody would be mad.

Heck, if one wanted to, one could use the Hah!IdontneedEFI as the field that my bootloader checks, it would just be the default value written with the bootsector, and the sector would give priority to the EFI partition (eventually). It wouldn't affect code size at all to put it at a fixed location. Technically you could even overwrite the EFI partition GUID to give whatever you want priority boot.

You may try first stage loader from my boot tools. It loads from GPT partition on legacy BIOS systems.
See the link in my signature.