[BUG] SD2 Makes Arch R fail to boot

[MrRocketFX]

Describe the bug

Using 2 SD Cards will cause the system to fail to boot

How to reproduce

Flash a fresh copy of Arch R and let the setup run like normal then shutdown.
Insert Second SD Card "TF2-GAME"
Boot
The screen will be black for a few seconds
then report it cannot find mmcblk1p1 and will start a counter to shutdown

Information

• ArchR Version: [e.g. 20260316]
• Hardware Platform: R36S (HL-R36H-V21 2024-11-18)

[MrRocketFX]

The issues seems to be with the exfat driver formatting the card to Fat32 seems to work.
the odd thing is it works when formatted as exfat only after boot

[MrRocketFX]

nope still busted it seems just stuck on the black screen

[dgateles]

Hi @MrRocketFX — thanks for the report and the follow-up. This was a real bug; fixed in 0689a89c47 on new-arch, will land in the next build.

Root cause

The RK3326 has two SD slots: TF1 (where the OS lives) and TF2. The Linux kernel enumerates the MMC controllers by device-tree order:

• ff380000.mmc → mmc0 → /dev/mmcblk0 (TF2)
• ff370000.mmc → mmc1 → /dev/mmcblk1 (TF1, OS)

U-Boot enumerates by probe order, and when TF2 is populated U-Boot can hand a different devnum to the boot script than what the kernel will eventually call /dev/mmcblk1. The boot.ini was hardcoded to:

setenv partition_boot "/dev/mmcblk${devnum}p${distro_bootpart}"
setenv partition_root "/dev/mmcblk${devnum}p2"
setenv partition_storage "/dev/mmcblk${devnum}p3"

…so the kernel got boot=/dev/mmcblk0p1 root=/dev/mmcblk0p2 (or whatever stray devnum U-Boot picked) and the busybox /init script failed to find it → black screen + countdown.

Why "exfat" looked like a workaround

It wasn't actually the filesystem; it was the timing of the U-Boot probe. exFAT and FAT32 each take slightly different times for U-Boot to scan, which sometimes ended up with U-Boot landing on TF1 first by luck. Hence the inconsistent behavior you saw.

Fix

Switched partition_{boot,root,storage} to use partition labels instead of device paths:

setenv partition_boot "LABEL=ARCHR"
setenv partition_root "LABEL=ARCHR_ROOT"
setenv partition_storage "LABEL=STORAGE"

The kernel cmdline now reads boot=LABEL=ARCHR root=LABEL=ARCHR_ROOT disk=LABEL=STORAGE, and the /init busybox already resolves LABEL= via findfs + a blkid scan across /dev/mmcblk{0,1}p{1,2,3} — so the correct partitions are found regardless of which slot U-Boot enumerated first. Survives any 2-SD configuration, including TF2 with a stale ArchR install.

For the next stable build

You'll need to reflash to pick up the new boot.scr (the bootloader sits in the protected area before /flash, an update via archr-update only refreshes the rootfs). The flasher in the repo (archr-linux/archr-flasher) writes the whole image atomically.

Closing on the next ArchR release that includes this; reopen if you still see the issue after reflashing.

[dgateles]

The label-based boot fix shipped in 2.0 and is included in 2.1 (https://github.com/archr-linux/Arch-R/releases/tag/v2.1). Your last test predates it, so please reflash with the current image (the bootloader only updates on a reflash) and try the two-card setup again. Closing as fixed; reopen if it still fails on 2.1.