Of BIOS and UEFI: A shim??
Of BIOS and UEFI: A shim??
I have a laptop that will not allow anything but UEFI and I must run FreeDOS.. (or one of many other OSes that wont boot via UEFI)
Is there a UEFI Bios shim? UEFI thinks it is an OS, but It loads the BIOS boot block and runs it?
Is that even possible?
might be possible to use seabios as a UEFI boot and have it act as a bios (as it is a bios "emulator"), never been down that rabbit hole, but perhaps there is someone who has if you search / ask around
Git repo of seabios: https://github.com/coreboot/seabios/tree/master
not sure if it will work, just hit me when I read this. anyways, good luck, hope you get it sorted/working 🙂
You could always run it on top of 86box. There are YouTube tutorials on setting it up for various hardware levels.
Actually, I do have a quite usable FreeDOS running in DOSBox on my Linux machine, but it's not quite the same as running DOS / FreeDOS on the metal. Getting floppies to work as seamlessly as they do on a machine meant for DOS for example.
86box is a little different than dosbox in that it fully emulates the hardware. Performance might still be an issue in your case, though. I have an emulated voodoo banshee system for playing old games and it works great for my use case of supporting old glide games. My thinking being if it can support glide emulation that it would be able to support anything from the dos era. I could be wrong though.
OSes that expect BIOS have some expectations that would be hard to meet in the UEFI application execution environment: BIOS ROM at a specific memory address, processor in real mode, and probably expecting to find some other legacy hardware even though that's not strictly a BIOS thing.
Maybe you could use the CPU's virtualization features to implement a low-level virtual machine with a BIOS implementation in it, launched directly from the UEFI environment, but would the entire OS then be running in that VM? 🤔
Linux for example will boot easily under both UEFI and BIOS - but I suppose that is because Linux does not ask anything of either once it is running.
Indeed, I was thinking about OSes like DOS that use the BIOS API even at runtime, for tasks like accessing disks.
As you say, Linux is built for the same world that UEFI was built for, where the firmware is mostly used only to boot the system and for low-level stuff like power management. In that case, the "boot services" in UEFI help to get the kernel loaded and then that takes over most of the hardware interactions. Linux uses BIOS in the same limited way it uses UEFI.
But the IO.SYS in DOS (on IBM PC-compatible platforms, at least) is effectively a wrapper around the BIOS interrupts, and applications running under DOS also expect to be able to interact with BIOS directly sometimes, so I think to do what was asked would mean the OS effectively running inside the UEFI "boot services" environment, rather than the usual approach of the UEFI application only dealing with early boot and then transferring control fully to the OS.
(UEFI does have a legacy compatibility layer that I've been ignoring for the sake of this discussion because it's something normally built in to your firmware rather than something you can add yourself. But it is technically possible for a BIOS implementation to run in that environment. I don't think it's possible for a normal UEFI application to use that facility, but I might be wrong about that.)