[PATCH] arm64: dts: amlogic: meson-sm1-odroid: let the SD card be powered down

[PATCH] arm64: dts: amlogic: meson-sm1-odroid: let the SD card be powered down

[Igor Velkov via B4 Relay]

From: Igor Velkov <iav@iav.lv>

A warm reboot leaves the ODROID-HC4 in the bootloader: the card is still
detected - CID and CSD read fine - but data transfers fail, and both
U-Boot and the boot ROM give up on CMD18. A cold power cycle always
recovers it.

The card is left in UHS mode at 1.8 V, and nothing after Linux brings it
back to 3.3 V: the bootloader resets the controller, not the card. The
kernel does try to cut the power on the way out - mmc_bus_shutdown() ends
in _mmc_sd_suspend(), which calls mmc_power_off(), and meson-gx-mmc then
disables the vmmc regulator - but TFLASH_VDD is marked
regulator-always-on, so the regulator core keeps it enabled and the card
keeps its supply.

Drop the property. The regulator has a consumer that manages it, and
regulator-boot-on already describes the state it comes up in.

Tested on ODROID-HC4 with a card that reproduces the failure. Not tested
on ODROID-C4, which shares this file.

Fixes: 326e57518b0d ("arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4")
Assisted-by: LLM
Signed-off-by: Igor Velkov <iav@iav.lv>
---
 arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
index e6f02d738a21..7dbc75bfaea2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
@@ -38,7 +38,6 @@ tflash_vdd: regulator-tflash-vdd {
 		gpio = <&gpio_ao GPIOAO_3 GPIO_OPEN_DRAIN>;
 		enable-active-high;
 		regulator-boot-on;
-		regulator-always-on;
 	};
 
 	tf_io: gpio-regulator-tf-io {

---
base-commit: b44e2be772f866985cafdf90355285069ea68495
change-id: 20261003-hc4-sd-power-off-67d3f58f1304

Best regards,
-- 
Igor Velkov <iav@iav.lv>

Re: [PATCH] arm64: dts: amlogic: meson-sm1-odroid: let the SD card be powered down

[Igor Velkov]

Please drop this patch. With the SPI flash erased, so that the boot ROM
loads U-Boot from the SD card, a warm reboot with this change fails 2/2
(the ROM loops on SD:800); compare dc7f2cb218b5 for ODROID-N2. The
4/4 reboots I tested went through U-Boot in SPI flash, which powers the
card itself.

--
Igor Velkov

Re: [PATCH] arm64: dts: amlogic: meson-sm1-odroid: let the SD card be powered down

[Igor Velkov]

Follow-up to the dropped patch.

An out-of-tree restart handler [1] power-cycles the card: it drives
TFLASH_VDD and both tf_io lines low for 100 ms, then releases them and
the card is powered again. With the SPI flash erased, ODROID-HC4 boots
from SD after a warm reboot 5/5 on 6.18, 7.2 and 7.3-rc5. Without the
handler the boot stalls in the ROM or in U-Boot.

Where should this live upstream: the mmc core on restart, meson-gx-mmc,
or a board driver like this one?

[1] https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-7.3/meson64-reboot-02-port-to-gpiod.patch

--
Igor Velkov

Re: [PATCH] arm64: dts: amlogic: meson-sm1-odroid: let the SD card be powered down

[Christian Hewitt]

> On 8 Oct 2026, at 1:05 am, Igor Velkov <iav@iav.lv> wrote:
> 
> Follow-up to the dropped patch.
> 
> An out-of-tree restart handler [1] power-cycles the card: it drives
> TFLASH_VDD and both tf_io lines low for 100 ms, then releases them and
> the card is powered again. With the SPI flash erased, ODROID-HC4 boots
> from SD after a warm reboot 5/5 on 6.18, 7.2 and 7.3-rc5. Without the
> handler the boot stalls in the ROM or in U-Boot.
> 
> Where should this live upstream: the mmc core on restart, meson-gx-mmc,
> or a board driver like this one?
> 
> [1] https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-7.3/meson64-reboot-02-port-to-gpiod.patch

I’ve been doing some bring-up work on S4 support with a VIM1S board
and Claude initially suggested a u-boot variant of the same patch [1]
which improved but did not fully resolve the situation. I was also not
able to explain why applying the same change via the Linux device-tree
that u-boot consumes didn’t have the same effect as essentially the
same change in the u-boot dtsi file.

Claude subsequently added a second patch [2] which resulted in 100%
reliable boot. However that allowed me to move forwards with kernel
work and I haven’t yet circled back to u-boot to run an experiment
without the first patch.

[1] https://github.com/chewitt/u-boot/commit/0a3f5693a4ff192eb044fc4c5a434770de053835
[2] https://github.com/chewitt/u-boot/commit/8e663632bc500ee6a83a846bcd3242231c33aa43

As usual both of Claude’s authoritatively worded descriptions sound
convincingly or conveniently good :)

Christian