From silent UART to a working NanoPi R2S

August 19, 2026 · RK3328 · UART · Alpine Linux

Today I brought a NanoPi R2S from a completely silent serial console to a verified Alpine Linux boot. The board was healthy. Two independent problems had hidden that fact: an intermittent USB–TTL path and a 64 GB SD card flashed with an image for the wrong Rockchip family.

The result

With a replacement serial adapter and the correct official FriendlyELEC RK3328 image, the board spoke immediately at 1,500,000 baud. The log identified a NanoPi R2S, U-Boot 2017.09, Linux 6.6.134+, and Alpine Linux 3.23.4. I had left the UART VCC pin disconnected and used only ground plus crossed TX and RX, so the adapter observed the board without trying to power it.

Hardware
NanoPi R2S Rockchip RK3328 and 1 GB RAM
Serial proof
1,500,000 baud Dedicated 3.3 V debug UART
Booted system
Alpine 3.23.4 Linux 6.6.134+ after U-Boot 2017.09
Storage after first boot
58.9 GiB userdata Backup GPT repaired and userdata expanded

How the silence was isolated

  1. Start with the instrument. The first USB–TTL adapter and jumper path behaved intermittently in loopback, so silence at the board could not yet be trusted as evidence about the board.
  2. Replace one uncertain link. A replacement adapter passed repeated loopbacks at both 115200 and 1,500,000 baud. That made the serial path a known-good measuring tool.
  3. Inspect the boot medium. The original SD card contained a Rockchip image from the RK3588 family, not an R2S/RK3328 image. Its early boot code could never match this chip.
  4. Build and verify the right image. I assembled and flashed the official FriendlyELEC RK3328 Alpine image, then compared the boot-critical region byte-for-byte before putting the card into the board.
  5. Read the first real evidence. U-Boot appeared over UART, Linux continued, Alpine reached its login environment, and the system reported the correct board identity.

The important shift was treating every link as a separate hypothesis. A silent terminal did not mean a dead board; it meant only that the complete path had not yet produced readable bytes.

What actually boots

An SD card for this board is not just a Linux filesystem. The RK3328 begins with code built into the chip, then reads several board-specific stages from raw locations on the card before it can start a kernel.

  1. 01
    Boot ROM Fixed inside the RK3328
  2. 02
    IDB loader Raw early loader on the SD card
  3. 03
    Trusted firmware Prepares the secure handoff
  4. 04
    U-Boot Finds and starts the operating system
  5. 05
    Linux + device tree Kernel plus the R2S hardware description
  6. 06
    Alpine root filesystem The installed userspace
  7. 07
    OpenRC services SSH and other configured services
Each stage only needs to load the next one. Seeing the U-Boot banner proves stages 1–4 before Linux or the root filesystem is involved.

What is on the SD card

The working card combines raw boot components, small support regions, a compact Alpine system, and a large data partition. On first boot the image repaired the backup GPT at the end of the larger card and grew userdata to use the remaining space.

Early boot raw area IDB loader, trusted firmware, U-Boot
Boot support small regions misc, DTBO, resources, kernel and boot files
Alpine rootfs about 448 MiB The compact operating system
userdata about 58.9 GiB Expanded on first boot
Conceptual rather than to scale: the tiny raw boot regions at the front matter just as much as the visible filesystems.

A quiet, healthy first boot

I kept the first health pass read-only. The board reported about 946 MB of total memory with about 851 MB available, a temperature near 44 °C, and low load. Configured services, including SSH, started. Both Ethernet ports correctly showed no carrier because no cables were attached. The hardware clock was old, and the remaining boot warnings were nonfatal defaults rather than failed hardware.

SSH being ready is useful, but it also sets the next safety boundary: the vendor-default root password must be changed before either Ethernet port is connected. I am deliberately not recording that password here.

The lesson I will reuse

A U-Boot banner over UART is already a strong milestone. It proves that the RK3328 Boot ROM found the raw loader, trusted firmware ran, and U-Boot started. A Linux kernel and root filesystem are not required to reach that point.

The three UART wires can stay fixed while I experiment with operating systems, but the software side is not interchangeable. Each image must enable the correct serial console and may need its own loader, firmware, U-Boot, kernel, and device tree.

Next experiments

Ubuntu, Debian, OpenWrt, and FreeBSD are all useful next directions; FreeBSD's current hardware notes include both RK3328 and NanoPi R2S. I will use one separate SD card per operating system and preserve today's Alpine card unchanged as the recovery baseline. That turns a successful investigation into a dependable way back.