How MINIX boots — and how Ouroboros differs

MINIX's boot sequence (x86, the canonical platform)

MINIX boots the old-fashioned way, then pivots hard into its microkernel structure:

1. BIOS reads the first sector and executes it — ordinary MBR-style boot, no UEFI. That code loads /boot/boot, the MINIX Boot Monitor, MINIX's own small boot-loading program.
2. The Boot Monitor loads /boot/image — a multi-part file containing several separate programs packed together: the kernel, plus the initial set of user-space servers. It also reads boot environment variables that configure driver behaviour.
3. The kernel starts, initializing itself and its own kernel-resident tasks — CLOCK and SYSTEM, plus IPC — before anything in user space runs.
4. The kernel starts PM and VFS — the Process Manager and Virtual File System, the first two user-space processes. PM gets PID 0 and is genuinely the first thing running outside the kernel.
5. RS, the Reincarnation Server, becomes parent of every other boot-image process, including init. This is what gives MINIX its fault-tolerance story: RS can restart a crashed driver or server without restarting the whole system, because drivers and servers were never part of the trusted kernel.
6. init runs /etc/rc, which starts everything that wasn't in the boot image — PCI enumeration, disk controllers, the keyboard driver, networking, procfs — before finally starting login.

So the boot image is deliberately minimal, and everything else — every real device driver, the TCP/IP stack, procfs — is a separate, independently-restartable user-space process started later, not compiled into the kernel at all.

MINIX's ARM port: a genuinely different chain

MINIX's canonical platform is x86; its ARM port (BeagleBoard/ BeagleBone-class Cortex-A8 SoCs) boots much closer to embedded ARM Linux: U-Boot, a third-party bootloader, loads the MINIX kernel at a fixed, hardcoded memory address (0x80200000) and jumps to it directly — there is no MINIX-authored boot monitor on ARM.

From the MINIX developers, directly

"There is no UEFI support whatsoever; MINIX 3 for now expects an IBM PC compatible computer on i386. On ARM everything is pretty much hard-coded right now." A real admission from the project's own mailing list, not speculation.

Ouroboros's boot sequence, for comparison

1. UEFI firmware loads the kernel directly as a UEFI application — no MBR, no boot sector, no separate boot-monitor stage. A deliberate choice specific to the primary target (Parallels on Apple Silicon), which boots ARM VMs exclusively through UEFI with no direct-kernel shortcut.
2. The kernel does its own console discovery and loads its userland programs (the shell and the filesystem server, per config) — still using UEFI boot services, the same window MINIX's boot monitor would occupy.
3. exit_boot_services — the one-way transition out of the UEFI world. Nothing before this resembles a "kernel"; everything after it does.
4. The kernel installs its own exception vectors, then its own MMU identity map, replacing firmware's page tables — a step with no equivalent in MINIX's sequence, specific to arriving at EL1 with the MMU already active.
5. Interrupt controller + timer init, then the kernel drops to EL0 — running the loaded shell, the idle task, and the filesystem server.

Side by side

What this says about Ouroboros

When these notes were first written, Ouroboros was considerably more monolithic than either MINIX platform — MMU, exceptions, drivers, and scheduling all undifferentiated EL1 code, with nothing in user space but a demo. That has since changed for four components: the filesystem, the console, the network stack and account management each run as an isolated, supervised, restartable userland server, reached over sendrec-shaped IPC with grant/safecopy capability copies — MINIX's sys_safecopy and its reincarnation server, in miniature. The gap versus MINIX is now breadth, not the absence of the model: four servers rather than a full fleet, no VFS or process manager, no process trees. MINIX's boot sequence remains the concrete existence proof of the fuller version — a typed set of cooperating servers started in dependency order, each independently replaceable.

Patterns worth revisiting

• A "boot image" of more than one program. Ouroboros already loads a shell and a filesystem server at boot — a natural step toward MINIX packing kernel + PM + VFS + RS together; config could name a list of programs to start.
• A supervisor / restart process (MINIX's RS). Ouroboros now has a special-cased version of exactly this for its filesystem server; the general form — any registered server health-checked and restarted — is the natural next step.
• MINIX's ARM boot chain is the cautionary comparison, not the aspirational one. U-Boot, a fixed load address, "everything hard-coded" — a reminder that Ouroboros's UEFI-native, address-discovered approach is already ahead of what MINIX's own ARM port does, for reasons this project learned the hard way (a hardcoded QEMU address once hard-crashed real Parallels hardware).

The full note, with sources linked throughout, lives in the repository as research-minix-boot.md.