The BOOTBOOT loader has exactly the opposite philosophy than GRUB, it is not a Grand Unified Loader, rather a set of simple and small loaders which provide the same boot environment for your kernel on different platforms.
This loader was created to an easy alternative to the complex GRUB by one of the OSDev forum members.
BOOTBOOT can load your 64 bit kernel on the following platforms:
- Raspberry Pi (AArch64)
- Legacy BIOS (x86_64 with MBR)
- Legacy BIOS boot with any arbitrary boot manager (x86_64, chainloaded from VBR)
- Legacy BIOS boot with a single OS on a forward-compatible GPT disk (x86_64, booted from PMBR)
- Legacy BIOS for embedded systems (x86_64, in BIOS Expansion ROM)
- UEFI (x86_64)
- UEFI for embedded systems (x86_64, in PCI Option ROM)
- CDROM, El Torito "no emulation" BIOS boot (x86_64, hybrid GPT/ISO9660 image)
- CDROM, El Torito UEFI boot Extension (x86_64)
- ISOLINUX / LILO / BOOTLIN / etc. (x86_64 via the Linux kernel boot protocol)
For GRUB compatibility, BOOTBOOT is also Multiboot compliant, so you can add it to the grub.cfg in it's own entry. This is useful if want to dual boot multiple OSes.
Your kernel can be wrapped in an initial ramdisk archive (USTAR, cpio, James Molloy's initrd format etc.), which in turn can be a simple file on a FAT16/32 partition; or can occupy the whole partition as well using a file system of your choosing (SFS among others). BOOTBOOT uses GPT partitions, so your boot partition should be either an ESP, or it should have the bootable flag (attribute 2) set.
If despite the warning you decide to Roll Your Own Filesystem, then BOOTBOOT is definitely for you. You can either write an FS module (one function), or just make sure the kernel is the first executable in the archive / on the partition. BOOTBOOT is capable of loading kernels from unknown file systems as well.
Optionally you can load your OS from ROM (see qemu's -option-rom command line argument, or bochs rc file), and the Raspberry Pi version can also load the ramdisk over serial line. Although it's not implemented as of yet, the BOOTBOOT protocol allows loading the initrd from a TFTP server.
You can use ELF64 or PE32+ formats for your kernel. You must link it as a Higher Half Kernel, and your entry point should point to Long Mode code. No real mode nor protected mode trampoline code needed at all, which simplifies your build environment significantly. Example linker script provided for both x86_64 and AArch64.
BOOTBOOT passes a configuration to your kernel in a newline separated, zero-terminated UTF-8 string. Each line contains a key=value pair, where only two keys, "screen" and "kernel" are reserved. You are free to use any other keys that your kernel wishes to use.
BOOTBOOT does not support VGA text mode, it sets up graphic mode regardless to the platform. You don't have to mess around with VESA or GOP any more, you will get the frame buffer ready to use. The example Hello World kernel provided with the BOOTBOOT source has a minimal puts() example, which outputs text on that frame buffer using PC Screen Font (same that Linux Console uses).
The loader also initializes the serial console for you with 115200 baud, 8 data bits, no parity and 1 stop bit. Your kernel can send debug messages from the start.
Besides of the pre-compiled boot loader binaries, BOOTBOOT also provides dependency free tools written in ANSI C to map GPT EFI System Partition into MBR, install boot sectors or send your ramdisk over serial line from another machine. The aforementioned Hello World kernel can be used as a skeleton for your kernel. Forget the boot process, you can start by implementing your kernel right away.
For all the features and available options, read the PDF documentation. It describes how to install an initial ramdisk with your kernel in it on a disk image, what are the exact memory mappings, which C structure is used to pass information to your kernel, how to tell bootstrap processor from application processors apart, etc.