flat assembler
Message board for the users of flat assembler.

Index > OS Construction > BIOS and UEFI: how to support both?

Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 807
Location: Belarus
DimonSoft
I want to write my own operating system (well, in fact I only want to find out more about the OS construction by means of diving into it, but that doesn't matter). The question that worries me a lot is how to write a bootloader that is aware of both old-fashioned BIOS firmware and brand new UEFI. As far as I can understand, at least the execution environment for the two cases will be different.

So, where should I start from if I want an OS to be oth BIOS- and UEFI-aware?

[Obviously, I'd like to use FASM only, no C/C++/C#/Java/AnyOther"Cool"ProgrammingLanguageUselessInOSDev]
Post 01 Apr 2014, 08:53
View user's profile Send private message Visit poster's website Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Not possible, you must have different loaders for both, For BIOS your loader wI'll have to manually switch to Long Mode, while UEFI already sets up the processor for you. BIOS uses boot sector method while UEFI will load an entire Image from a FAT Formatted Volume. One way could be that your boot sector or EFI Image can pass a value in a register ex: EDX will be set to 0xFFFF if firmware is UEFI and 0x004F if firmware is BIOS, then your loader can check the value of EDX and accordingly execute code.
And BTW C is the language of OSDev, all the major operating systems are written in C (Windows, Linux, BSD), and C provides maximum portability and control (lesser than assembly though), C has been used for OSDev across platforms, it's considered unusual by most programmers if you're using assembly for OSdev, but C fanboys don't know the power of assembly they're lost in their own world, it's like writing a poem in Spanish using Google Translate to translate it to English and then wondering why no one likes it. (JohnFound's Signature iirc)
Post 01 Apr 2014, 09:22
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 807
Location: Belarus
DimonSoft
sid123 wrote:
Not possible, you must have different loaders for both, For BIOS your loader wI'll have to manually switch to Long Mode, while UEFI already sets up the processor for you. BIOS uses boot sector method while UEFI will load an entire Image from a FAT Formatted Volume. One way could be that your boot sector or EFI Image can pass a value in a register ex: EDX will be set to 0xFFFF if firmware is UEFI and 0x004F if firmware is BIOS, then your loader can check the value of EDX and accordingly execute code.
And BTW C is the language of OSDev, all the major operating systems are written in C (Windows, Linux, BSD), and C provides maximum portability and control (lesser than assembly though), C has been used for OSDev across platforms, it's considered unusual by most programmers if you're using assembly for OSdev, but C fanboys don't know the power of assembly they're lost in their own world, it's like writing a poem in Spanish using Google Translate to translate it to English and then wondering why no one likes it. (JohnFound's Signature iirc)

I see. I'll ask one more question. I'm currently not sure if my own notebook has UEFI support. What things should I be aware of to minimize the amount of code to rewrite when (if?) I finally switch to UEFI?
Post 01 Apr 2014, 09:46
View user's profile Send private message Visit poster's website Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
hi DimonSoft,
To check whether you notebook supports UEFI booting just go into the Firmware settings and you should
see a "Secure Boot" and an "Enable UEFI Boot Option", if your laptop is younger than 5 years it should support UEFI (although UEFI came in 2006, but many vendors didn't support it that time).
1. Never ever ever ever ever × π ÷ 0 use BIOS Interrupts in your kernel, you should rely on your boot loader to pass information in a standard way. All at the most you'll need the memory map and video mode information,
Boot Drive Information and absolutely nothing else. If you're new you MAY use SMM code like writing a driver for a PS/2 Keyboard. However you must get through this quick, write a USB interface, then work on a an HID implementation and grab data from the Keyboard without using PS/2 Emulation. A USB Stack isn't a trivial approach and if you're writing a USB Stack in assembly, it's a overkill.
Back on topic, do not rely on SMM code very much.
2. Never ever ever ever × π ÷ 0 switch back to Real Mode or use Death 8086 Mode, just forget about that.
If you want to switch video modes after boot, then I'd say it's a crap choice. What you could do is configure the maximum resolution that is supported by the monitor on boot (ask the user), and emulate a specific resolution inside the screen. Say the monitor is 1366×768 pixels wide, and a program requests for say 640×480 resolution, what you can do is fool the program by making it believe it's a 640×480 screen and then make the draw limits smaller, so the user will see a small 640×480 box inside the screen, that is a screen inside a screen!
Post 03 Apr 2014, 09:26
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.