OSDev.org

So, I've been writing a UEFI OS. Of course, we all want our OSes to run on all systems, not just UEFI.
However, I've been thinking. GRUB2 has a nice set of drivers and module support. It even provides the same flat memory model as UEFI.
So, what's to prevent GRUB2 emulating UEFI firmware? OK, not the full runtime service thing, but I don't see a significant subset being too difficult.
Thoughts?

Not sure what your after..

Is your idea that your OS would only support UEFI boot and it would work directly with UEFI machines and on BIOS machines you would use GRUB2 and it should provide UEFI environment so your bootstrap still works?

Wouldn't it be better and simpler to separate the two distinct concerns:
- OS/kernel doesn't care how it gets instantiated, it just wants to be a good OS/kernel
- Bootstrap is firmware specific (BIOS or UEFI, or something else for other than PC platforms) and it's job is to instantiate your OS

So write your UEFI bootstrap in such a manner that it "instantiates" your OS and then you can write another one for BIOS, and the latter stages of both can and likely would be nearly identical.

I don't really see much benefit in trying to make BIOS look like UEFI, given that the other solution is more reliable since trying to "translate" all UEFI stuff into BIOS stuff in such a manner that it always works is pretty much impossible, unless GRUB2 becomes even more of an OS in and of itself.

Runtime services are a tiny portion of UEFI, probably you meant Boot Services (and bunch of protocols for doing things like various I/O for storage and overall peripheralls (SATA, USB and PCIe are alone a monstrous thing each, but there are a lot yet - SD/MMC, NAND for example), graphics, consoles, driver binding, device paths, various networking things like TCP/IP, TFTP, iSCSI, PXE, etc etc)?

And why "emulating"? Is it religiously forbidden for it to even think it could "implement" it? Who knows better than the GRUB developers? I think they know better. Since I am working with mips and arm SBCs I have no idea about GRUB, but I heard it is able to play role a UEFI OsLoader, so maybe this is their way - they don't think it's needed for them to compete with Tianocore, which already supplies a base ground, massive framework, in fact, for traditional BIOS makers, now making UEFI? They just don't want. How does that idea look to you?

Personally, I don't see any reason for hobby OSes aiming at x86 to support legacy protocols like BIOS. It's just work for the past, not future. UEFI is getting widespread, so if you ever will have users for your OS, they most probably will be more comfortable with UEFI than BIOS. It's like learning assembly by books talking about 16-bit real mode and DOS. Somehow it's often seen even now.

I disagree. While most modern PCs support both UEFI and BIOS not all emulators support UEFI. Most users will probably run a hobby OS on an emulator and they might use an emulator which does not support UEFI like Bochs.

Not only that, but few people are willing to "hand over" expensive, up-to-date hardware for testing a hobby OS on (whether it's their own or someone elses). Much more likely that they'll have a few-generations-old PC sitting in a cupboard somewhere with nothing on it that they don't mind losing...

For what it's worth I think there are a few legacy BIOS boot loaders like Chameleon that emulate (U)EFI for the purpose of booting macOS on non-EFI systems.

This is somewhat off-topic but you might find this interesting: https://www.cnx-software.com/2016/08/11 ... platforms/

that is what I called "working for the past".

you won't test your own creature on the "up-to-date" hardware even having it? you hate your OS!

well, it's a little stereotyped. like "new hardware" necessarily means a several times overpriced new iSomething(R) device from you know. Nowadays one could buy a little and cute and inexpensive x86 SBC with all the new features, still quite affordable by price. Exactly for testing his/her own OS. Or have something not bloody new, but still quite modern. different flea markets suggest all the spectrum for all prices. shortly speaking it's a very bad excuse to still mess around BIOS/DOS/16 bits in 2017. And finally, "testing the OS" is not going to burn out your shiny rig. The biggest damage would either nihilizing data on the storage - easily overcome, just use an empty drive, or bricking the board. only if you play with the FW, which is improbable, but that still is kind of revertible.


uboot...


last time I checked their "support", most Services were just stubs. It's not implementing UEFI, it's mimicking and pretending you do so. they just managed to run some primitive UEFI applications. Noone with a sane psychic would use uboot for UEFI on arm. There is Tianocore which is a true UEFI implementation. uboot is a messy linux only kind of loader.