Writing an OS with UEFI [closed]

Question

I haven't been coding much lately due to school but I've decided I want to start working on OS development again. Recently however I've heard stuff about EFI as the replacement to BIOS. I want to develop an OS for a platform that uses EFI rather than BIOS. I'm having trouble figuring out where to start though. Can anyone point me in the right direction? Maybe explain what EFI means to OS development and maybe tell me what testing environments (preferably virtual) I can use. Quite frankly, I'm not really sure exactly what EFI is. Also should I invest time looking into ARM assembly? I know x86 Assembly but I feel as that is becoming outdated as well. I'm really lost and I would love to hear your input.

Thanks

Answer 1

EFI is the precursor to UEFI, which is what people actually use, although they still sometimes refer to the thing as EFI. You can get the specifications involved at uefi.org.

The UEFI Specification defines everything a boot loader might need to know. The PI Specifications define interfaces for silicon vendors to use for portability of their code in the industry. So you will hear about an OS, like Win8, requiring compliance with a certain version of the UEFI Specification, like 2.3.1c, for some features to work, like secure boot. All this goes to say that EFI does not replace BIOS so much as become a standard to which the BIOS must comply to support some operating systems.

The place to go to get started (after you get a copy of the specifications) is the TianoCore project on SourceForge. One of the projects there is OVMF, which is a virtual machine target for UEFI. You may also want to look at the NT32 target for running a command prompt under windows. These are really great tools to use when you want to design an application, like a boot loader, that sits on top of the UEFI interfaces.

As far as learning assembly, I don't recommend you start there. There is so much to know, and part of the reason that we created UEFI is so that new programmers could work in C instead of ASM. There are a few places in UEFI where we use ASM, but the build system handles the details for splicing that in, and you generally don't need either the tricky control of the state of the processor or the performance you would get from writing the ASM. The only other reason you would do it is size, and since the rest of the BIOS is going to be in C, it sort of defeats the purpose unless you rewrite the whole thing in ASM, which no one is going to do. Focus on learning the specifications and how to use them to write your own UEFI applications.