Porting legacy BIOS-based OS to UEFI

[austanss]

I'm having a crisis right now.

I've been working on my OS "microNET" for about two weeks.

https://github.com/microNET-OS/microCORE

I've added partial keyboard support (my conversion table is incomplete). I've decided, since my interrupts were stable and my OS was running fine in QEMU, I'd dd it to my third hard drive and boot it. Simple, it dded fine and it showed up in the BIOS. Then I get a message:


WARNING: no console will be available to OS
error: no suitable video mode found


I reboot my computer and look up the issue. I find out that my bootloader needs to be UEFI-conformant. Okay... it should be, it's kinda booting.

Much to my horror, I find out UEFI has no text mode support.

I look up how much of a pain this will be to fix. Well, I Google it, and I find out it requires quite a rewrite of my OS. I'll be required to develop a bitmap font and rewrite my terminal class.

I'm in a crisis. I don't know where to start here, I don't know what to do. I've looked at the UEFI Bare Bones, however this doesn't give me quite enough information. I haven't found any Google results online for porting existing legacy-based OSes to UEFI. This revelation is putting my ambition for the project at stake. I need help.

[Octocontrabass]

We have an overview on the wiki.

I suggest plotting pixels into a bitmap image in an ordinary user application alongside something like libpng or SDL. Once you understand how that works, you'll have no trouble putting that to practice in your kernel.

The multiboot2 specification covers the data structures you'll need to parse in order to find information about your frame buffer.

[alexfru]

Rendering monospaced bitmap fonts is trivial and there are plenty of fonts online. Making your own (for ASCII and most Latin scripts, at least) isn't too hard. Write the code. Make it portable and to test it quickly, dump the rendered stuff to a simple bitmap file (BMP, specifically, 24 bpp without compression) that you can then see with standard tools on your host/dev OS. No drama here.

[austanss]

Rendering monospaced bitmap fonts is trivial and there are plenty of fonts online. Making your own (for ASCII and most Latin scripts, at least) isn't too hard. Write the code. Make it portable and to test it quickly, dump the rendered stuff to a simple bitmap file (BMP, specifically, 24 bpp without compression) that you can then see with standard tools on your host/dev OS. No drama here.

Not only the text is important here. I need to know if my interrupts will be affected, my keyboard support, the whole boot process, I don't know what needs to be changed.

[Octocontrabass]

You probably don't need to change anything but the graphics output. Most UEFI hardware still implements legacy components.

ACPI indicates whether dual 8259 interrupt controllers exist in the MADT. ACPI indicates whether the 8042 PS/2 keyboard controller exists in the FADT.

[bzt]

Much to my horror, I find out UEFI has no text mode support.

Once you have set up the linear frame buffer, it works exactly no matter if you have used VESA and GOP, there's no difference.

Rendering monospaced bitmap fonts is trivial and there are plenty of fonts online. Making your own (for ASCII and most Latin scripts, at least) isn't too hard. Write the code. Make it portable and to test it quickly, dump the rendered stuff to a simple bitmap file (BMP, specifically, 24 bpp without compression) that you can then see with standard tools on your host/dev OS. No drama here.

Not only the text is important here. I need to know if my interrupts will be affected, my keyboard support, the whole boot process, I don't know what needs to be changed.

About the fonts, you could use PC Screen Font, that's what Linux uses (meaning you can use the fonts shipped with your distro). The wiki contains an example C code how to display characters.

You can also use my SSFN library, it is an stb-style header only ANSI C implementation, designed to be portable and already tested on x86_64 and AArch64 bare metal. The ssfn_putc() renderer was designed specifically for kernel consoles (absolutely no dependencies, no function calls at all), but it supports only unscaled bitmap fonts. The normal renderer has some memory related dependencies (malloc for example), but it can display vector fonts as well. Example fonts are available in the repo, plus you can convert virtually all font formats into SSFN.

About the interrupts, those are handled by the CPU, so no matter what firmware you use.

The same stands for peripherals: no matter the firmware, you can always use them. You'll only lack the firmware provided interface. For example, to send characters to the serial port, with BIOS you would use int 14h, while under UEFI you'd use SERIAL_IO protocol. Regardless the IO ports 0x3f5 are accessible for both, because IO ports are independent to the firmware.

Cheers,
bzt