Edge kernel image parameters

[Marco Schirrmeister]

The page for the NanoPi R76S has also an edge kernel (6.18) image.

 

I noticed some issues related to sdcard and emmc. I know edge images are not officially supported and that is fine. But given the image is available I would like the parameters/configuration/conditions for the current available image.

Could you explain the background or assumptions behind the 6.18 edge image for the R76S? (e.g., test conditions you used when building it)

[eselarm]

There are 2 sentences below that set of download URLs that should say enough:

Quote

 

* Edge kernels are actively developed, so there may be some unreported issues on this images. You should beware of that.

* Most of images are tested with test automation or by Armbian community or official maintainers.

 

 

Also see section title: "Bleeding" in normal life means something went wrong, blood dripping from your body might spoil the carpet, blood squirting from your body might mean death is near. So you are expected to do something maybe. You already did by doing that by creating this topic.

 

In case of a device with new SoC (on the market after old 6.1 kernel) it seems wise to put also focus on new mainline kernel which is maybe a bit problematic w.r.t. certain things, but you can be sure it will be the main stable thing sometime. Maybe after years.

If people who care about such a device/computer/board would only stick to old/stable Rockchip proprietary downstream kernel and firmware, this thing will be dead after 5 years from now. So in order to survive, it needs development/testing now and continuously actually (also w.r.t. security, that is the case for every computer). You are one of the testers, maybe you forgot to realize. 'images' is very low effort getting an integrated and pre-installed OS tested. If no images, you would point people to a rootfs.tar.gz or instructions to run debootstrap and let people guess how to build a kernel and some bootloader. Or run Debian Testing or a rolling distro like Arch Linux.

 

You would be a better tester if you could more exactly inform where or what the issue is. Maybe it is so simple like a week ago or so that a listed image was only containing U-Boot, so the .xz file was something like  500 kilo not Mega Bytes.

[Marco Schirrmeister]

I don't think I forgot anything. I was just curious about the conditions for the current version, since these sentences are relative generic and don't list issues, before I layout the details that I noticed. 

 

I flashed the image to a SanDisk Ultra, A1, Class 10 sdcard. System booted fine, but was relative slow which seemed to be related to constant sdcard speed switching issues. The following was constantly going on in the logs.

 

[Wed Dec  3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[Wed Dec  3 13:30:34 2025] mmc_host mmc1: Bus speed (slot 0) = 198000000Hz (slot req 200000000Hz, actual 198000000HZ div = 0)
[Wed Dec  3 13:30:34 2025] dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 235

 

The workaround for this was changing power control from auto to on. Messages stopped after executing the following.

 

cat /sys/devices/platform/soc/2a310000.mmc/power/control
auto
    
echo on > /sys/devices/platform/soc/2a310000.mmc/power/control
    
cat /sys/devices/platform/soc/2a310000.mmc/power/control
on

 

My permanent workaround was this, to avoid manual intervention after a reboot.

 

# /usr/local/sbin/fix‑sd‑pm.sh
#!/bin/sh
# Disable runtime PM for SD controller (fixes repeated re-init)
echo on > /sys/devices/platform/soc/2a310000.mmc/power/control

# /etc/systemd/system/fix-sd-pm.service
[Unit]
Description=Disable runtime‑PM for SD controller
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/fix‑sd‑pm.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

# Enable
chmod +x /usr/local/sbin/fix‑sd‑pm.sh
systemctl daemon-reload
systemctl enable --now fix-sd-pm.service
systemctl status fix-sd-pm.service

 

Without the workaround the mmc1 switched between 2 states. 

 

root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name
SD128

root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios

clock:      400000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:    0 (don't care)
power mode: 2 (on)
bus width:  0 (1 bits)
timing spec:    0 (legacy)
signal voltage: 0 (3.30 V)
driver type:    0 (driver type B)

# OR

clock:      200000000 Hz
actual clock:   198000000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:    0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

 

With the workaround it always showed this and system felt also snappy.

 

root@nanopir76s ~# cat /sys/class/mmc_host/mmc1/mmc1:*/name
SD128
root@nanopir76s ~# grep . /sys/kernel/debug/mmc1/ios
clock:      200000000 Hz
actual clock:   198000000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:    0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)
root@nanopir76s ~#

 

---

 

EMMC was visible under Linux. But the emmc problem I noticed is related to u-boot.

When I flashed the image to emmc and started from sdcard nothing at all happened. If I boot from sdcard and interrupt the u-boot prompt, the emmc card was not really visible. or accessible. I do not have the full serial output anymore when the Armbian image was flashed to emmc.

 

=> mmc list
mmc@2a310000: 0 (SD)
mmc@2a320000: 2
=>

# switching to emmc gives this

=> mmc dev 2
Card did not respond to voltage select! : -110
mmc_init: -95, time 22
=>

 

To debug this better, I build my own u-boot and image based on Armbians dts and defconfig.

Here is what it looks like when booted from emmc with no sdcard inserted.

 

U-Boot SPL 2026.01-msc-1 (Dec 02 2025 - 23:42:14 +0100)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
mmc_init: -95, time 21
spl: mmc init failed with error: -95
Error: -95
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

 

I created a patch for the dts, which modifies the sdmmc and sdhci nodes in the dts file. The patch is in my u-boot repo. https://github.com/mschirrmeister/PKGBUILDs/blob/f02af83ae5e0180ae1fd50706624dee348b820d7/core/uboot-rk3576-nanopi-r76s/arm64-dts-rockchip-rk3576-nanopi-r76s-fix-sdmmc-sdhci-coexistence.patch

 

I added also the following Kconfig options to the u-boot defconfig.

 

CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
CONFIG_MMC_HS200_SUPPORT=y
CONFIG_MMC_HS400_SUPPORT=y
CONFIG_MMC_HS400_ES_SUPPORT=y

 

Here is the raw patch data.

 

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Marco Schirrmeister <mschirrmeister@gmail.com>
Date: Sat, 6 Dec 2025 23:56:46 +0100
Subject: [PATCH] arm64: dts: rockchip: rk3576-nanopi-r76s: fix sdmmc/sdhci coexistence

The NanoPi R76S (RK3576) features both a DW‑MMC controller for the
microSD socket (sdmmc) and an Arasan SDHCI controller for the on‑board
eMMC (sdhci).  When both were enabled, the shared I/O voltage rail caused
initialisation conflicts: the eMMC required 1.8 V signalling while the
SD card logic expected 3.3 V.

This patch aligns the DTS and U‑Boot configuration so that both storage
controllers operate correctly:

- Enable CONFIG_MMC_SDHCI and CONFIG_MMC_SDHCI_ROCKCHIP in U‑Boot.
- Add explicit `vmmc-supply` and `vqmmc-supply` properties to the
  eMMC (sdhci) node.
- Add `no-1-8-v;` to the SDMMC node to keep the µSD socket fixed at
  3.3 V.

With these adjustments the board can access both the microSD and eMMC
devices simultaneously, and U‑Boot can boot directly from either medium.

Signed-off-by: Marco Schirrmeister <mschirrmeister@gmail.com>
---
diff --git a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts
index 11111111111..22222222222 100644
+++ a/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:33:40.013947291 +0100
+++ b/dts/upstream/src/arm64/rockchip/rk3576-nanopi-r76s.dts 2025-12-06 23:56:46.961392491 +0100
@@ -772,6 +772,7 @@
 	status = "okay";
 };
 
+/* eMMC on the Arasan/SDHCI host */
 &sdhci {
 	bus-width = <8>;
 	full-pwr-cycle-in-suspend;
@@ -781,9 +782,13 @@
 	no-sdio;
 	no-sd;
 	non-removable;
+	/* add the supply rails for completeness */
+	vmmc-supply  = <&vcc_3v3_s3>;  /* main VCC rail */
+	vqmmc-supply = <&vcc_1v8_s3>;  /* I/O rail */
 	status = "okay";
 };
 
+/* µSD socket on the DW‑MMC host */
 &sdmmc {
 	max-frequency = <200000000>;
 	no-sdio;
@@ -795,6 +800,8 @@
 	sd-uhs-sdr104;
 	vmmc-supply = <&vcc_3v3_s3>;
 	vqmmc-supply = <&vccio_sd_s0>;
+	/* keep this host at 3.3 V so it works when eMMC uses 1.8 V */
+	no-1-8-v;
 	pinctrl-names = "default";
 	status = "okay";
 };

 

With this patch and config changes u-boot detects emmc fine and I can boot from either emmc or sdcard. 

If this changes are good or bad, I have absolutely no idea.