UEFI Wiki updates

[PeterX]

You don't know what GDT it has set up, and at the end of the day you'll have to use your own no matter what. Likewise, you can't use its paging tables, so you'll have to use your own.

Isn't that normal? I mean, look at multiboot specification: You have to setup your own GDT there, too.

My EFI loader took me a week to make, and my BIOS took me two

Which is irrelevant A software is written once, and executed many many times.

To me that is NOT irrelevant! Aren't nearly all programmers lazy?

As for startup speed, it fluctuates. 4 seconds is about average. I am fine with it, and have gotten used to it. So I will get rid of my BIOS loader soon.

You must be still young to have time to waste My time is lot more precious than wasting it on waiting for VMs to boot. When I actively do development, I test my OS very often, and those seconds accumulate. They build up to minutes and even hours pretty quickly. But do as you please!

Of course you could reboot on real hardware. I bet that takes more than 4 seconds.

Generally speaking I see where UEFI sucks. But in other aspects it's quite cool. It's usable in C. It's 64bit. It's portable. I can handle large disks. It has GPT with much more partitions than MBR.

Greetings
Peter

[nexos]

Once you're in long mode, it shouldn't matter to your kernel how you got there. And just for the records, UEFI using long mode is more of a problem than a blessing, you'll see for yourself later. You don't know what GDT it has set up, and at the end of the day you'll have to use your own no matter what. Likewise, you can't use its paging tables, so you'll have to use your own. When you got to the point to finally implement user space and user mode, you'll realize that you had to rewrite everything that UEFI has given to you, so it was a total waste of resources on UEFI's part... Just wait and you'll see!

No difference then GRUB, as @PeterX pointed out. I just don't load the segment registers until I set up my own GDT. As for paging, I am writing that code right now. UEFI has helped me out here. Because of the identity mapped environment, I can more easily access the buffer that the kernel was loaded into and map it according to the program header. I would be staring blank at my monitor doing that on my BIOS bootloader . Its really no different then GRUB. GRUB sets up a GDT, you overwrite it. You setup temporary paging tables for higher half mapping, that then gets overwritten. I don't no if BOOTBOOT does it differently, but for GRUB and UEFI, it is the same deal. Honestly, UEFI is easier then GRUB because now it sets up those temporary paging tables! While I am getting on board with UEFI, I will no get on board with Secure Boot. Period.

Besides, if you want to do SMP, you'll have to care about real mode and prot mode code, you can't get away with long mode only. UEFI will not initialize the APs into long mode, only the BSP. You'll still need to care about those "ancient" modes.

I see what your saying, but for me entering PMode or long mode is just a matter of setting registers. My last OSes trampoline code was very short. I already have a GDT and PML4, which makes the trampoline code easy IMO.

Greetings,
nexos

[PeterX]

While we are talking about downsides of UEFI: I must admit that I have a hard time with EDK2 because it is so darn big and complicated, even its build process. But I have an even harder time with GNU-EFI. I can well understand nostalgia for BIOS int calls, because I could write a text output routine or a floppy read routine right from my memory if someone wakes me upp in the middle of the night. But I don't want to end up like those guys who write still DOS clones... No disrespect for their work, they can do what they like. But I prefer modern hardware and OSs.

...Oh, we got carried away from the original topic. I would say adding UEFI links to Bare Bones and Bootloader pages would be cool.

Greetings
Peter

[nexos]

I must admit that I have a hard time with EDK2 because it is so darn big and complicated, even its build process. But I have an even harder time with GNU-EFI.

I might split off this discussion . Anyway, don't use either. What I do is simply use MinGW for Linux with a command line as follows

Code: Select all

x86_64-w64-mingw32-gcc -MD -ffreestanding -I../../Include -IInclude -IEfiHeaders -IEfiHeaders/x86_64 -IEfiHeaders/protocol -DEFI -c EfiBootProt/Loader.c -o EfiBootProt/Loader.o

And then I copied the header files from GNU-EFI. I then include efi.h, and directly access the System Table. True, you do have to write basic library functions like strlen, memcpy, memset, etc, but you don't have to flicker with complicated build environments.

[bzt]

Isn't that normal? I mean, look at multiboot specification: You have to setup your own GDT there, too.

Exactly my point. UEFI using long mode has no advantage whatsoever, you'll have to set up everything yourself at the end of the day.

Of course you could reboot on real hardware. I bet that takes more than 4 seconds.

Actually no. All my testbeds boots up in less than a sec. The funkiest of all is the RaspberryPi3, because it's using and old monitor with a HDMI-VGA converter. By the time the monitor turns on and adjusts to the screen resolution, the OS is already loaded

Generally speaking I see where UEFI sucks. But in other aspects it's quite cool. It's usable in C. It's 64bit.

These are true for all other firmware as well. For example, xv6 boot sector is written in C (it only needs a very minimal Asm to enable A20 and set up stack). You can also use SmallerC to write code for BIOS loaders (check out if you haven't already, it's truly a great project). By default, coreboot payloads are implemented in C. I've implemented my RaspberryPi loader in C. Etc. etc. etc. Using Assembly is not a must (except for a very minimal initialization code), however I find it simpler to be used with a boot loader (but that's just me).

It's portable.

Now this part I never understand. Nobody needs a portable firmware. A firmware should initialize a given motherboard with all of its components, that's all. If you move it to another platform, that's going to have completely different devices anyway... I think coreboot's philosophy is better: it is not portable at all, but you can compile it for many different platforms with many different drivers! It has a directory full of compile configurations, each for a particular motherboard. Simple. I like simple

I can handle large disks. It has GPT with much more partitions than MBR.

Okay, large disks is a plus. But you can use GPT with BIOS and coreboot as well. I even use GPT for my RaspberryPi loader without probs. As long as a firmware provides a sector load function, you can have any partitioning table you want (GPT included).

But I have an even harder time with GNU-EFI.

Why? It's plain simple. Works out of the box. I guess I should write a GNU-efi tutorial on the wiki?

I don't no if BOOTBOOT does it differently, but for GRUB and UEFI, it is the same deal. Honestly, UEFI is easier then GRUB because now it sets up those temporary paging tables!

I don't follow. Neither GRUB nor UEFI sets up paging tables for higher-half kernel. BOOTBOOT has to do it no matter what firmware it's running on.

While I am getting on board with UEFI, I will no get on board with Secure Boot. Period.

That I can absolutely understand and relate with!

I see what your saying, but for me entering PMode or long mode is just a matter of setting registers.

But how can you be sure that the paging table that the long mode UEFI allocated for you is below 4G? You see, if it's above 4G, then your prot-mode trampoline code will set up an invalid CR3 before it jumps to the long mode segment (PML4 address truncated to 32 bit)... And if you don't use the UEFI provided paging tables, but create one for the APs yourself, then UEFI did not helped you at all!

True, you do have to write basic library functions like strlen, memcpy, memset, etc

That's why I also link with GNU-efi. It provides all those for you! It's just in the braindead UEFI parlance they have different names! For example memcmp is called CompareMem, memcpy is called CopyMem, strlen is called strlena (because StrLen is for wchar_t) etc. I haven't checked memset, because I only use it to zero out memory and there's ZeroMem for that. The libefi.a also provides uefi_call_wrapper, so that I don't have to care about the actual ABI.

But I prefer modern hardware and OSs.

So do I. I'm not saying that do not implement UEFI loaders. Not at all! I've implemented BOOTBOOT for UEFI, because it is important and some machines require it. All I'm saying is, just because you've implemented an UEFI loader, doesn't mean you have to use it in your VM all the time, especially if you also have a much-much faster loader implementation

Cheers,
bzt

[PeterX]

All my testbeds boots up in less than a sec.

Then your computer(s) is/are a lot faster to boot than mine.

Now this part I never understand. Nobody needs a portable firmware. A firmware should initialize a given motherboard with all of its components, that's all. If you move it to another platform, that's going to have completely different devices anyway... I think coreboot's philosophy is better: it is not portable at all, but you can compile it for many different platforms with many different drivers! It has a directory full of compile configurations, each for a particular motherboard. Simple. I like simple

Actually you are right on that.

I guess I should write a GNU-efi tutorial on the wiki?

I would like to see that.

Greetings
Peter

[nexos]

I agree mostly with you bzt, except for this one thing:

Now this part I never understand. Nobody needs a portable firmware. A firmware should initialize a given motherboard with all of its components, that's all. If you move it to another platform, that's going to have completely different devices anyway... I think coreboot's philosophy is better: it is not portable at all, but you can compile it for many different platforms with many different drivers! It has a directory full of compile configurations, each for a particular motherboard. Simple. I like simple

I like simple too. UEFI's portability is an advantage. For example, I want to port my bootloader to RPi 3. My bootloader is more of a boot manager, so it takes keyboard input. On BIOS, its easy. I use INT 16h. On UEFI x86_64, its easy. I use ST->ConIn. On RPi 3, its a nightmare. I have to implement PCI-E, USB, and USB HID just to read a keypress. I am fine with doing that in the OS itself. But that's a little much for a boot manager. I then found out about a project which is Tianocore for RPi. This will make making a boot manager much easier, as I can share most code related to UEFI. So its portability makes it easier to port to USB centered platforms like RPi .

[zaval]

Oh, well. just a few notes. bzt, you are wrong about disk block level access and switching video modes "unavailability", or them being "optional". You misunderstood again. Just like you misunderstand protocols purpose - they all are Boot Services phase entities and they all are gone after OS takes control over. It's intentional. And it's strange, that those, who whine the most about "evil firmware from evil corporations is sticking up its nose in our business", find themselves not liking the idea of firmware getting out after having done with the OS loading. It's alogical. You easy read blocks of storages and switch video modes with UEFI. The requirememnts of UEFI are flexible, but clear. For example, if a machine is supposed to have a display attached, then GOP/STIOP will be present. And you will be able to switch modes. Using protocol handling services for dealing with protocols is not a sign of a feature being "optional", it's a UEFI way of getting to the functionality and it's good.
Next, GPT "number of partitions". it's well defined, actually. The field NumberOfPartitionEntries is the number of allocated partitions. All unallocated entries must have all fields zero, so there is no ambiguity, in fact. CRC is calculated over only what is allocated. All zero area of the array is just a free space of the container for future use. They might have formulated it a little bit clearer, but no, UEFI doesn't suggest both meanings as you claim.
And finally, extensibility. you know, there are hundreds of cases, where this embedded in the standard property, may be useful and there is not a single one, where it can hurt. Of course, if not counting butthurt from the linux torvalds followers camp. The two most obvious things about extensibility 1) the mentioned above flexibility of requirements, with extensible nature of the standrad, it's easier to implement the former, the flexibility. Like that very same GOP for example. Say, if you provide support for an LCD panel, that is going to be attached to the machine, you provide UEFI driver, implementing GOP for this panel. You don't need all the FW "sauce", don't need to compile all the FW, you just write your LCD controller driver and in doing so, you can rely on the well defined interface and services, provided to you by the FW. You add your functionality and easy integrate it into the FW. And 2) loads of different scenarios, where something exotic, might be really useful - some USB vendor defined protocols, FS support, other than FAT, touchscreen input support for smartphones, some fancy network booting etc. extensibility doesn't hurt.

[bzt]

I like simple too. UEFI's portability is an advantage. For example, I want to port my bootloader to RPi 3. My bootloader is more of a boot manager, so it takes keyboard input. On BIOS, its easy. I use INT 16h. On UEFI x86_64, its easy. I use ST->ConIn. On RPi 3, its a nightmare. I have to implement PCI-E, USB, and USB HID just to read a keypress. I am fine with doing that in the OS itself. But that's a little much for a boot manager. I then found out about a project which is Tianocore for RPi. This will make making a boot manager much easier, as I can share most code related to UEFI. So its portability makes it easier to port to USB centered platforms like RPi .

Okay, you're talking about the portability of a loader, not the portability of the firmware. That makes lot more sense.

Btw, implementing USB in a boot loader sucks, no question about that, but there are many Open Source libraries which are a lot easier to simply link with than to get UEFI working (there's csud USB HID library, LdB's USB lib, and last but not least, Circle C++ with a fully blown USB stack). Furthermore, even if you manage to get UEFI running on an RPi, it would waste lots of RAM, which is a very precious resource as there's only 1G (and the GPU also using a big amount of it), and it would definitely slow down the boot considerably. For example, there's a Multiboot port for RPi, which is *a lot* smaller than the UEFI codebase, yet it is bloated enough not be widely used.

Oh, well. just a few notes. bzt, you are wrong about disk block level access and switching video modes "unavailability", or them being "optional". You misunderstood again.

Oh, am I? Is there a mystic disk driver and video interface next to the ConIn and ConOut in the EFI_SYSTEM_TABLE that I don't know about? Because only interfaces in the system table are guaranteed to be available. LocateProtocol might return NULL any time...

you misunderstand protocols purpose - they all are Boot Services phase entities and they all are gone after OS takes control over. It's intentional.

I didn't misunderstood, that's exactly why I said it should be called "Big Bloated Boot Environment", and not a "Firmware Interface". I know very well that those protocols are inaccessible for the OS. Just because this was intentional, doesn't mean it is a good design (it's obviously not).

For example, if a machine is supposed to have a display attached, then GOP/STIOP will be present.
...
Using protocol handling services for dealing with protocols is not a sign of a feature being "optional"

You are clearly contradicting yourself here. You said it yourself that GOP might not be present. Therefore GOP is optional. But what a much bigger problem is, there's no guarantee that you'll get EFI_SIMPLE_FILE_PROTOCOL or EFI_BLOCKIO_PROTOCOL. How do you load an OS if LocateProtocol returns NULL for those? (I would say DISKIO_PROTOCOL, but that never even worked for me on a real hw.)

Oh, why do I even bother answering you? We all know you're a payed Microsoft troll, you're deaf to reasoning.

Cheers,
bzt

[nexos]

I didn't create this thread just to turn into another bzt vs. zaval war. bzt doesn't care for UEFI and Microsoft, zaval loves them both. They really should just add each other to there foes list. Before this gets out of hand, it might be a good idea to lock this thread.

[PeterX]

Okay, you're talking about the portability of a loader, not the portability of the firmware. That makes lot more sense.

I made a mistake there. Making it easier to port a loader or a kernel is a good thing and an advantage of UEFI. (Of course the kernel is still a lot different on different architectures.) The firmware shouldn't be portable except maybe some parts of it (and even that is questionable).

Greetings
Peter

[bzt]

I didn't create this thread just to turn into another bzt vs. zaval war.

And it won't, you have my word.

bzt doesn't care for UEFI and Microsoft

That's not entirely true. What I don't like about UEFI is that it goes against K.I.S.S. principle, and that instead of providing a widely spread standard it's been used as a tool to lock down computers. There's no way that an OSDever in the XXI. century can get around it, so we must care, that's why I have written so many wiki pages on the topic. And I don't hate Microsoft either (well, not more than any other company that forces sh*t down on customers' throat, because all they care about is profit, nothing else. This attitude is by no means unique to Microsoft). For example I admire them for providing binary API backward compatibility so long. That's an amazing technical achievement, no other OS was able to do that, but Windows. Its kernel has a lot better design than Linux will ever have, no doubt.

I made a mistake there. Making it easier to port a loader or a kernel is a good thing and an advantage of UEFI.

Yeah, me too. Talking about portable loader or kernel is a different thing than talking about a portable firmware. Sorry, I misunderstood that!

Cheers,
bzt

[PeterX]

Maybe we can get back to the original topic:

I would say adding UEFI links to Bare Bones and Bootloader pages would be cool.

Is there a list of all UEFI related pages? They are quite some.

Greetings
Peter

[bzt]

I guess I should write a GNU-efi tutorial on the wiki?

I would like to see that.

Here you go: GNU-EFI. First draft, I've tried to put and explain everything important on that page. Btw, UEFI page has a paragraph about GNU_EFI, I've put a link to this new page there.

Is there a list of all UEFI related pages?

Should be this, but I'm not entirely sure that all related pages have a "Category:UEFI" added.

Cheers,
bzt

[PeterX]

Thanks for the GNU-EFI page!

Is there a list of all UEFI related pages?

Should be this, but I'm not entirely sure that all related pages have a "Category:UEFI" added.

Definitively not all have been added. There are a lot of UEFI related pages. I've tried to add the catogries Firmware and UEFI to all UEFI pages I could find. Including Xenos' UEFI Bare Bones page which is very good.

Greetings
Peter