Source: https://mayphus.org/entries/nanopi-r2s-freebsd-ram-boot/
Title: From a U-Boot prompt to FreeBSD in RAM
Metadata: {"date":"2026-10-07","kind":"article","language":"en","locale":"en","route":"/entries/nanopi-r2s-freebsd-ram-boot/","slug":"entries/nanopi-r2s-freebsd-ram-boot","tags":["nanopi-r2s","freebsd","boot"],"type":"article"}

# From a U-Boot prompt to FreeBSD in RAM

On September 22–23, 2026, I used an original NanoPi R2S to test a specific boot boundary: could FreeBSD reach a shell while its root filesystem lived entirely in RAM? The recorded answer is yes, after two failed handoff approaches. A separate SD installation later passed its own persistence test. This is a historical case study from the saved lab observations, not a new board test or a ready-made installation procedure.

The [earlier R2S bring-up](https://mayphus.org/nanopi-r2s-alpine-boot/) had already resolved a silent serial path and a wrong image. Here I started with a smaller proof. A 32 MiB U-Boot-only card image was read back byte-for-byte after writing. The physical board reached a U-Boot prompt, reported 1 GiB of RAM, detected the SD card, and accepted commands over the serial console. That established the bootloader and console before asking a kernel to work.

## Proving a RAM root first

I transferred a matching device tree, an Alpine Linux kernel, and an initramfs over serial, checking each payload with CRC32. Alpine reached a shell. The mount list then showed a RAM root and virtual filesystems, with no SD filesystem mounted. That second check mattered: a shell proves that a system booted, but it does not prove where its root filesystem resides.

The first FreeBSD path used the official kboot loader from that temporary Linux environment. It began loading the kernel but could not complete the handoff. The payload did not contain the configured memory-filesystem root, and the kernel handoff stopped when the required UEFI memory map was unavailable. Reaching a loader was not yet a FreeBSD boot.

## Giving the EFI loader a device

I next tried an EFI bridge backed by a read-only RAM disk. The first bridge made the bytes available and started the official EFI loader, but the loader still did not reach a kernel or shell. The revision associated the loaded EFI image with the RAM-backed block device. That distinction was the useful finding: the loader needed a usable firmware device relationship, not merely a region of memory containing files.

After a physical power cycle on September 23, all four transferred payloads passed on-board CRC32 checks. The loader read the kernel and memory-filesystem root from the RAM disk. FreeBSD 15.0-RELEASE reached an interactive single-user shell with a read-only 64 MiB memory-disk root; the mount check showed no SD filesystem. The recorded proof covers kernel boot, shell response, RAM residency, and the absence of a mounted SD root. It does not cover normal multi-user startup, networking in this RAM-boot stage, complete peripheral support, or a second cold-boot repetition of the RAM path.

## A separate persistence test

The later SD installation kept the bootloader and added an EFI partition and FreeBSD UFS root. Image read-back matched the source. The board booted from SD; a proof file survived reboot. After expanding UFS to 15 GB, another reboot returned to the shell with that file intact. Persistence came from those reboot observations, not from the earlier RAM shell.

At the end of this experiment, starting FreeBSD still required manual U-Boot commands and stopped in single-user mode. The build depended on the original lab's toolchain and downloaded components, so I am not presenting it as a one-command, independently reproduced recipe. [Later USB Ethernet work](https://mayphus.org/nanopi-r2s-freebsd-usb-ethernet/) investigated networking separately; its results should not be read back into this September boot proof.