Update — eMMC now detected (workaround found)
After significant debugging, I have identified and worked around the issue. Here's what I found:
What the shipped DTB is missing for the eMMC controller (/mmc@fe310000):
vmmc-supply / vqmmc-supply — voltage regulator references
pinctrl-0 / pinctrl-names — pin muxing for the 8-bit eMMC data bus, clock, command, and data strobe lines
cap-mmc-highspeed, mmc-hs200-1_8v, no-sd, no-sdio — eMMC capability flags
Interestingly, the PMU IO domains (syscon@fdc20000/io-domains) are already correctly configured with vccio2 = 1.8V, and the pinctrl groups (emmc-bus8, emmc-clk, emmc-cmd, emmc-datastrobe) exist under /pinctrl/emmc/. The board-level wiring is all there in the DTB — it's just not connected to the eMMC controller node.
Root cause: The Armbian Trixie vendor kernel (6.1.115) ships only rk3566-radxa-zero3.dtb (generic Zero 3), not the 3W-specific rk3566-radxa-zero-3w.dtb that the upstream Linux kernel has. The upstream DTS includes all of the above for the 3W model.
Additional finding — deferred probe timing issue: Even after patching all missing properties via a device tree overlay, the eMMC still doesn't appear on first boot. The SDHCI driver (sdhci-dwcmshc) probes before the overlay's regulators are registered, receives dummy regulators instead of deferring, and initializes the controller without real power. A manual unbind/rebind of the driver after boot causes immediate detection:
mmc0: new HS200 MMC card at address 0001
mmcblk0: mmc0:0001 8GTF4R 7.28 GiB
I have a working fix (overlay + early-boot driver rebind) that I testing before publishing.
The proper long-term solution would be for Armbian to ship the rk3566-radxa-zero-3w.dtb from the upstream kernel, or merge its board-level eMMC configuration into the existing rk3566-radxa-zero3.dtb.