UEFI compatibility

[IanSeyler]

Need to investigate what is required to boot with UEFI.

How to get the memory map?
Is a GPT (instead of MBR) partition format needed?
Where are the ACPI tables?

Easiest method is to use GRUB and load a multiboot file.

There is no text mode in UEFI! Graphics are required.

[ghost]

GPT is added, now. Memory map and system information will be passed to the kernel by either a register or the stack.

[ohnx]

Booting from UEFI is an interesting task.

First off, an EFI application (e.g. bootloader) is stored in the PE format and uses Microsoft's C calling conventions.

An EFI application is called with two parameters, the "image handle" and the system table. The system table is where there are interesting things; the ConfigurationTable variable is where the list of ACPI tables are stored following this format. Also of note in the configuration table are the Boot Services function table and the Runtime Services function table; these function tables are very useful for bootloaders. After the bootloader exits, only the Runtime Services functions are still safe to call, though. The function table is typically represented as a struct and the C headers required to do so are pretty common (e.g. a stripped-down version can be found here).

To get a memory map, call a function at an offset into the Boot Services function table. The returned memory map is not E820 and will need to be converted for use in Pure64 (if we want to keep backwards compatibility).

IIRC, in proper UEFI, MBR and GPT partition tables should both be supported. However, I'm not sure if this is the case in the wild.

There is text mode in UEFI! Actually, graphics mode can be a pain since we will need to embed our own font into the application if we want to print text during the bootup process. Not sure if we want to offload this to the OS, or keep it with Pure64.

Note that I have linked sources that are not the actual 2000+ page PDF put out by the UEFI Forum, since I doubt that many people have the time to read through all of the specification... The latest specification can be found on the UEFI Forum website.

[ghost]

@ohnx Supporting UEFI will likely require many changes in the BareMetal-kernel. That's okay. It should not be that hard to go from E820 to a different structure.

Currently, text is printed out through a serial port that we can view through QEMU.

I'm hesitant to make a solution for printing text to the screen. If anything, I would send it to a file, so that it has a tangible form on disk. But I'm open to suggestions.

[ghost]

I think my project could help you with this:
https://github.com/KNNSpeed/Simple-UEFI-Bootloader

Looks like you guys might be trying to do a similar thing.

Bear in mind UEFI compatibility can be pretty nasty when dealing with earlier (c. ~2011-2012) systems, as vendors didn't really like to follow spec back then. E.g. 0-byte reads fail on Intel boards, RAM "pollution" on startup, etc. Newer machines tend to be better about all this, except Macs whose wireless cards randomly DMA into your RAM (see https://mjg59.dreamwidth.org/11235.html).

[ghost]

@KNNSpeed I like the project you linked.

I was not aware how bad the adoption of UEFI was in that time period, that's pretty funny.

I'm not sure if we can use the GNU EFI implementation, it's incompatible with our BSD license the way I understand it.

The hurdle we're facing now is creating FAT file systems on the image. While there are tools that exist for this, they're mainly for Linux. We need to have a FAT library in house so that we can not only create the file system, but also read to and write from it in the file system loader. Once we get to that point, then we'll be able to reference bootloaders like yours to get an idea of what a working implementation looks like.

Thanks for the link!

[ghost]

No problem!
I guess libraries like FATFs (http://elm-chan.org/fsw/ff/00index_e.html) are out of the question, then?

Technically if you stayed in UEFI without calling ExitBootServices() you would have access to all the FAT functions already there, but I have a feeling you guys want to get out of boot land as fast as possible. A nice thing about UEFI is that it already does all of this for you, and you can actually use UEFI functions to set up a system how you like and then pass whatever you want to a kernel. ...Unless you're [eventually] trying to write your own UEFI firmware?

[ghost]

@knn I've thought about Pure64 as a UEFI firmware but for now that's more of an "eventually" kind of thing.

That file system library looks useful. Although I don't particularly like libraries that use global variables, it's small enough that it's easy to patch. The license looks like it's compatible.

@IanSeyler what do you think about importing FatFS source code into the Pure64 project?

[IanSeyler]

@tay10r If it will help with UEFI then sure.

[ghost]

@IanSeyler It will help with UEFI, yes. I'm working on porting the library now to see if it will work. We might not need to use the code in the actual bootloader. Mainly we need it in the utility program to create the filesystem and put the files into it.

[ghost]

Just to update everyone, I've began refactoring the FAT library that @KNNSpeed mentioned and you can see the progress in the new libfat repository.

Once that's done, I would like to make a way for users to put their kernels onto the disk file without having to compile them with the monolithic bundle of software that is mingw (since Microsoft's ABI is used in the UEFI standard.)