OSDev.org

Is it theoretically possible to boot the following (ordered by how difficult I imagine it is) in a UEFI class 3 machine:

1. 64-bit Linux kernel (with EFI stub)?

   I hope so!

2. 32-bit Linux kernel?

   I imagine it is possible and that a UEFI application could:

   • Possibly use the UEFI framework to gather information later needed for the linux x86 boot protocol.
   • Read the kernel and copy to its desired load address.
   • Drop from long mode to protected mode and jump to the kernel's protected mode entry point.

3. 16-bit helloworld bootloader that only uses the BIOS functions to print to screen and halts?

   • Use UEFI framework to find out which graphics mode the hardware supports.
   • Copy 16-bit code that implements the BIOS print character routine somewhere in low memory and point the IVT 0x10 entry to it.
   • Maybe other BIOS interrupts also need to be implemented?
   • Copy the helloworld bootloader to 0000:7c00.
   • Drop to real mode and jump to the bootloader.

4. A 32-bit OS that goes to protected mode as fast as possible and never goes back to real mode?

   • Same as before, but also implement other BIOS services, like disk access?

5. Real mode code that writes to memory hardware mapped stuff like, idk, VGA screen memory?

To sum up: how much of CSM is based on software (that could be theoretically re-implemented by a UEFI app) and how much of it is hardware?

pensebem wrote:64-bit Linux kernel (with EFI stub)?

Yes, and it can also be done without the stub (e.g. using GRUB).

pensebem wrote:32-bit Linux kernel?

Works fine on 32-bit UEFI. GRUB seems to be able to boot a 32-bit Linux kernel on 64-bit UEFI, but I've never tried it.

pensebem wrote:16-bit helloworld bootloader that only uses the BIOS functions to print to screen and halts?

If there's RAM at the appropriate addresses, yes, you could drop your code into it and make it work, though you'll have to use a bitmap framebuffer instead of VGA text mode. If there's no RAM where you need it, you could use virtual 8086 mode with paging to fix things, but that's starting to get into hypervisor territory.

pensebem wrote:A 32-bit OS that goes to protected mode as fast as possible and never goes back to real mode?

How many assumptions about legacy hardware does this OS make? If your class 3 UEFI hardware can't meet those assumptions, you'll need a hypervisor.

pensebem wrote:Real mode code that writes to memory hardware mapped stuff like, idk, VGA screen memory?

If you've already got a hypervisor for that 32-bit OS from earlier, you might as well use it here too, although virtual 8086 mode might also be an option depending on exactly how this code expects to interact with the hardware.