OSDev.org

Hello,
I'm trying to write my first simple OS bootloader and I want to do it with UEFI. Right now I'm able to write a simple application with gnu-efi, compile it, copy it on a hard disk image and load it with qemu+ovmf (basically, UEFI Bare Bones).

I want now to switch to EDK2 because it seems like it is more complete than gnu-efi(also, I want to avoid that ugly uefi_call_wrapper( ), but I think I could avoid it simply playing with something like -DEFIAPI=__attribute__((ms_abi))).

I was able to build EDK2 as explained here and run the HelloWorld example, but I cannot figure out how to properly organize the files(e.g. *.h files in /usr/include/edk2, and the remaining stuff in /usr/lib/edk2) so I can reuse them whenever I need to. Currently I use the workflow explained in points 5 and 6 here, but I want to be able to create my project folder wherever I want for the sake of simplicity.

Has anybody else tried to do something like this? Any help or hint is appreciated.

I don't think its possible to use EDK2 without using their particular build system. This was one of the inspirations for the UEFI Bare Bones article. Please note that the method described there does not rely on using uefi_call_wrapper from gnu-efi but rather a toolchain which natively targets PE executables and the Microsoft x64 ABI.

As regards the base UEFI API, there is very little in EDK2 which is not in the gnu-efi headers. There are several interface structures and GUIDs not defined, but you can copy-paste these from the UEFI documents verbatim and use them. The maintainer seems willing to accept patches of these.

The bits which are missing are various support routines, all the hardware modules and particularly a standard C library. It is possible to build these modules directly in EDK2 and then use them in your own project. For example, I have used the Ps2Mouse module from EDK2 as a loadable module in my bootloader so I have mouse support (this is not included by default in the OVMF build used in emulators). I have not tried using the UEFI C library this way, as I ended up writing my own instead (here if you are interested).

Regards,
John.

Thanks jnc100, now it's a bit more clear