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.

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)

With the following options configured as a built-in module, the issue does not happen anymore on a poweron. CONFIG_TYPEC=y CONFIG_TYPEC_TCPM=y CONFIG_TYPEC_TCPCI=y CONFIG_TYPEC_FUSB302=y CONFIG_PHY_ROCKCHIP_USBDP=y I can create a pull request for the linux-rockchip64-edge.config file. But not sure what the general consensus on the kernel options for Armbian kernels is. Maybe it is also fixable via some code change, but that would be something for a real kernel developer.

This also happens on other kernels. Issue is present on final 6.18.0 kernel as well as on the older 6.12 kernel. It seems to be related to some kernel options that are set to "m". Need to figure out which kernel options would need to be set to "y" (built-in) on Armbian to avoid this issue on power-on.

Just an information about the `edge` kernel (6.18) when used on the cm3588-nas system. The rtc driver is not initialized on a `poweron`. After a poweron, you will see the following in the log. Nov 11 01:17:10 uhutest kernel: rtc-hym8563 6-0051: could not init device, -6 Nov 11 01:17:10 uhutest systemd[1]: System time advanced to built-in epoch: Tue 2025-11-11 01:17:09 CET If you have `fake-hwclock` running, you will see the following a moment later. fake-hwclock restores the time, but the service will not properly start, because of the rtc device error. Nov 11 01:17:12 uhutest fake-hwclock.sh[461]: Restoring saved system time Nov 20 13:22:43 uhutest fake-hwclock.sh[466]: Thu Nov 20 01:22:43 PM CET 2025 Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Cannot access the Hardware Clock via any known method. Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Use the --verbose option to see the details of our search for an access method. Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Main process exited, code=exited, status=1/FAILURE Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Failed with result 'exit-code'. Nov 20 13:22:43 uhutest systemd[1]: Failed to start Restore system time on boot and save it on shutdown. You would need to restart the fake-hwclock service, if you want that it saves time before the next restart. If you do a `restart` of the system, the rtc device will get properly initialized and time is good. Following is seen in the logs. Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: registered as rtc0 Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: setting system clock to 2025-11-20T12:26:11 UTC (1763641571) Nov 20 13:26:16 uhutest fake-hwclock.sh[455]: Not restoring old system time I have seen the issue right now only with the 6-18-RC kernel. The following patch mentioned here works as a pure workaround. https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/ Lets see how the development of kernel 6.18 goes and if the final version will not have this issue.

The 6.12.17-current-rockchip64 now works for me just fine. Wanted to test again and capture some verbose boot logs if it fails. But now it works just fine. Not sure if it is related to the patch from the pull request 7887, that was mentioned above.

On my OPi4LTS I do not have EMMC and it is stuck. Like I wrote it is stuck during hardware initialization, so I think it has no problem with finding the right kernel to boot.

I think the "apt list --upgradable" still shows packages that are hold. Run a "apt upgrade" and in there you should see what is held back. If all looks good, you can hit Y.

Of course can the OPi4LTS users install the rolling image. Which works fine, so no need for a custom build. But typically you don't want to run this on a production or stable machine. You never know what else will break down the road. Given that this works, the question is why does the 6.12 kernel images break the stable supported version. There is also no good way to debug, since all you see is initializing the hardware and then it is stuck at one point. But it is not fully clear what it does not like.

The real question is, why is is not booting or if it is supposed to be working. The download page has all kinds of images for the OPi4 with kernel 6.12, but it seems they do not work?

I would go with, like you wrote, ext4 or xfs. If something breaks, you can still mount the disk on any other linux system without any issue. Ext4 should also not have any problems with big file sizes. I am running xfs without any problems since years. Even if there was a hard crash, the filesystem could easily be mounted since nothing really happened on it or the recovery was smooth. I would probabyl still argue that ext4 is even more robust. For a simple disk to store some data it might still be the best choise.

I noticed the same and since I mainly run server stuff and don't rely on a monitor, my current workaround is modprobe -r synopsys_hdmirx. Don't know what this module is for, but console output is still working via hdmi. And to do it permanently, I have the following: root@dumpster ~# cat /etc/modprobe.d/hdmi.conf blacklist synopsys_hdmirx

A while ago I debugged the ssh problem and added some comments in this thread here. I don't remember if I used bookworm or trixie. Seems to me a timing issue or in which order things start. For now, whenever I do some dev work, I just do either another reboot after the first setup or restart the sshd service.

I think this issue here https://github.com/htop-dev/htop/issues/1160 describes the problem. Might be a problem that needs to be fixed within htop. If you are willing to switch tools, have a look at btop. That should give you should give you the overall temperature.

@Efe Çetin, PR is created. https://github.com/armbian/build/pull/6276 Bear with me, it is my first PR. So let me know whatever is wrong or needs to be changed.