OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Nov 25, 2020 10:18 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Porting legacy BIOS-based OS to UEFI
PostPosted: Mon Oct 19, 2020 9:06 pm 
Offline
Member
Member

Joined: Sun Oct 11, 2020 9:46 pm
Posts: 79
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.

_________________
Konichiwa, my OS dev friends.

<meme>
I am once again asking for your developmental support.
</meme>


Top
 Profile  
 
 Post subject: Re: Porting legacy BIOS-based OS to UEFI
PostPosted: Mon Oct 19, 2020 9:17 pm 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 2480
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.


Top
 Profile  
 
 Post subject: Re: Porting legacy BIOS-based OS to UEFI
PostPosted: Mon Oct 19, 2020 9:19 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1058
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.


Top
 Profile  
 
 Post subject: Re: Porting legacy BIOS-based OS to UEFI
PostPosted: Mon Oct 19, 2020 9:30 pm 
Offline
Member
Member

Joined: Sun Oct 11, 2020 9:46 pm
Posts: 79
alexfru wrote:
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.

_________________
Konichiwa, my OS dev friends.

<meme>
I am once again asking for your developmental support.
</meme>


Top
 Profile  
 
 Post subject: Re: Porting legacy BIOS-based OS to UEFI
PostPosted: Mon Oct 19, 2020 9:43 pm 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 2480
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.


Top
 Profile  
 
 Post subject: Re: Porting legacy BIOS-based OS to UEFI
PostPosted: Tue Oct 20, 2020 5:04 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1017
rizxt wrote:
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.

rizxt wrote:
alexfru wrote:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group