I’ve been working on an x86-64 assembly FAT32 library, now at version 1.0.0, aimed at OS development. Mainly to abstract out the responsibility from my OS.

A UEFI-started OS doesn’t necessarily need its own FAT32 implementation. Firmware can load the kernel and everything needed for startup in one pass. An OS also need not create its own boot medium. The library becomes useful when a project wants to take on those responsibilities:

1. Creating boot media. Format a FAT32 volume and populate it with boot files, configuration, and other resources. The sector provider can work with an image or a device; partition layout and bootloader installation remain the caller’s responsibility.
   
   
2. Loading components later. A kernel may want to load optional modules, drivers, or resources after startup. Once UEFI boot services have ended, the OS supplies a driver for the underlying medium. The FAT32 library sits above that driver and provides access to the files.
   
   
3. Integrating FAT32 into the OS. Expose ordinary file and directory operations through the OS’s filesystem interface, using shared file objects, independent handles, metadata operations, and explicit write transactions.

The design keeps the boundary at sector I/O. The library handles FAT32 interpretation; the caller supplies storage access, memory, synchronization, and the policy for making writes durable. The core has no OS imports or allocator dependency.

Diagnostics, formatting, streams, ordered commits, and read-only recovery facilities are optional. Functions are independently selectable at link time, with documented replacement contracts for consumers that need different behavior.

The implementation uses fasmg/fasm2 and the Microsoft x64 calling convention, with assembly and C interfaces. The repository includes a UEFI integration example, documentation, and a separate Windows testing harness.

MIT licensed. Feedback from OS developers—particularly on the interface boundaries and integration requirements—is welcome.

If you care about boot time this is probably a big fat NOPE - don't do it.

I'm talking about boot time from the user's perspective - not first presentation - big whoop, show a logo. That's marketing speak for, "We're slow, but buy our shit." First action is the end marker, and RDTSC at UEFI loader is the start marker. Cold boot should be so fast that showing a logo is practically meaningless.

UEFI just loaded the kernel from the ESP (EFI System Partition) and is prepared to read additional driver or configuration data. Not using that resource sets up a dependency chain - delaying access to hardware or early decisions, respectively.

Reading from within UEFI is the pattern the Linux EFI stub uses for its initrd. Windows also loads a lot from UEFI, but it also loads drivers - which Linux delays.

Great project!
Hope it blooms and bears fruit.

What fruit would you like to see?

I'm putting together a "leaving UEFI" post attempting to encapsulate the ideal setup - getting what is needed and handing off to the kernel. The hope is that one could almost bypass the UEFI spec and focus on their kernel.

Hi,bitRAKE
Building block structure, distributed system.
Looks it.

What building block were you going to work on?

Can you tell I hate branding and marketing? Buy a peripheral and get stickers, lights, GiBs of software to install - next it'll be a parade. Just make a better product.