MMUKO Boot is an experimental boot scaffold for building MMUKO as a freestanding operating-system environment rather than a normal hosted C application.
It currently supports two boot paths: a direct 512-byte BIOS boot sector and GRUB Multiboot. The direct path loads the kernel from disk, switches the CPU into 32-bit protected mode, and enters a freestanding C kernel_main(). The GRUB path performs the same MMUKO boot sequence through Multiboot.
The project runs under QEMU and includes assembly entry points, linker scripts, a freestanding C kernel, serial/VGA output, and Windows/Unix build paths.
I’m exploring how far the architecture can evolve toward a small, modular kernel with a stable ABI and independently replaceable components. Feedback on the boot architecture, kernel boundary, and next steps would be very welcome.
I wanted to check how slop is this, and came across this in the author's profile:
> I do not build software to scale. I build infrastructure to heal.
> I don’t do “hustle culture.” I do soul work, through computation.
I guess, bro.
MMUKO Boot is an experimental boot scaffold for building MMUKO as a freestanding operating-system environment rather than a normal hosted C application.
It currently supports two boot paths: a direct 512-byte BIOS boot sector and GRUB Multiboot. The direct path loads the kernel from disk, switches the CPU into 32-bit protected mode, and enters a freestanding C kernel_main(). The GRUB path performs the same MMUKO boot sequence through Multiboot.
The project runs under QEMU and includes assembly entry points, linker scripts, a freestanding C kernel, serial/VGA output, and Windows/Unix build paths.
I’m exploring how far the architecture can evolve toward a small, modular kernel with a stable ABI and independently replaceable components. Feedback on the boot architecture, kernel boundary, and next steps would be very welcome.