This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
I have been working for some time now on an x86-64 UEFI bootloader and a new boot protocol to go with it. I call it (the loader) Tosaithe and the protocol is TSBP (for Tosaithe Boot Protocol).
It is now at a stage where I am ready to formally announce it here, and request comments from members of the OSdev community.
Supports typical features: firmware info and memory map passed to kernel, framebuffer, command line, ram disk image.
The protocol is intended to be firmware agnostic, but the reference implementation (Tosaithe) is currently UEFI-only.
In contrast to other protocols:
Compared to multiboot (2), has native support for 64-bit kernels
Compared to LImine, it is (in my opinion) slightly simpler, but has all the essential features. It also has better support for using UEFI runtime services (i.e. provides a memory map that can be used to set up mapping via SetVirtualAddressMap() UEFI call). On the other hand, it is x86-64 only and the Tosaithe bootloader is much more primitive than Limine.
Please let me know if you have any feedback regarding the protocol, specification, or example. I am not so much seeking examples on the bootloader itself; I know that it is quite primitive. I would prefer constructive feedback - not bikeshedding! - and I welcome fair criticism.
There's no such thing as a 64-bit data segment, your DS/SS descriptors are probably actually 16-bit data segments. If you're not trying to provide segment descriptors that will be useful outside of 64-bit mode, you don't need any data segments at all - you can load DS and SS with null segments and be done with it.
Where will the GDT be located? It's not very clear.
What values will fields hold if they're not available? Some aren't specified.
How should the OS determine whether it was booted using UEFI or legacy BIOS?
Re the segment descriptors, I have even complained about the same thing in Limine so it's funny that I implied a 64-bit data segment. It is actually (as implemented at the moment) a 32-bit data segment, but I think I will take your suggestion and simply not have a data/stack segment and use null descriptors instead.
The GDT will be in "bootloader reclaimable" memory. The spec does say it is recommended that the kernel establish its own GDT early" but there's no reason not to be more specific so I will amend it.
I guess by the "not available fields" you mean pointers to things that might not be available (eg command line, ACPI RDSP?) In that case: if they are not available, they will be null. I will clarify this. Note that for the framebuffer fields it is specified that "fields are set to 0 if there is no framebuffer available". If the spec doesn't say "if available" or similar then the value is not optional, but I think I will amend this for the command line and allow null value if there is no command line.
In terms of how the kernel should determine whether it was booted by UEFI or legacy bios - if the UEFI memory map and UEFI system table are present, it was booted by UEFI. (They will either both be present or both not be present, since "if available" for both is dependent on whether it's a UEFI boot).
