meson64: driver-power-meson64-reset.patch breaks compilation on kernel 7.1

[EvilOlaf]

What happened?

7806104
This patch was disabled since it breaks compilation. of_gpio.h was removed upstream so this needs adaption to new API standard.
@pyavitz since this patch was from you, perhaps you find time to take a look into during rc phase.

How to reproduce?

./compile.sh BOARD=odroidn2 BRANCH=bleedingedge kernel
[...]
[🔨]   drivers/power/reset/meson64-reboot.c:37:10: fatal error: linux/of_gpio.h: No such file or directory
[🔨]      37 | #include <linux/of_gpio.h>
[🔨]         |          ^~~~~~~~~~~~~~~~~
[🔨]   compilation terminated.
[🔨]     CC [M]  drivers/usb/storage/sddr55.o
[🔨]   make[5]: *** [scripts/Makefile.build:292: drivers/power/reset/meson64-reboot.o] Error 1
[🔨]   make[4]: *** [scripts/Makefile.build:551: drivers/power/reset] Error 2
[🔨]   make[4]: *** Waiting for unfinished jobs....

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 24.04 Noble

Are you building on Windows WSL2?

• Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

https://paste.armbian.com/wovukojada

Code of Conduct

• I agree to follow this project's Code of Conduct

[pyavitz]

Tested on the Odroid N2 Plus

meson64-reboot-power-off-driver.patch

[mschirrmeister]

I tested this updated 7.1 patch on the Odroid-HC4 (SM1), but unfortunately, the SD card still is not being detected after a reboot. Is it possible there is a GPIO ownership conflict on this specific board that prevents the driver from initializing?

I peeked at the meson64-reboot node in the Device Tree and cross-referenced it with the running system. For example, sd-vqsw targets Pin 6, but my /sys/kernel/debug/gpio shows Pin 6 is already claimed by an always-on regulator:

gpiochip1: 15 GPIOs, parent: platform/ff800000.bus:pinctrl@14, aobus-banks:
 gpio-3   (                    |regulator-tflash-vdd) out hi
 gpio-6   (                    |TF_IO               ) out hi 

Trying to manually interact with the pin shows a deadlock:

echo 603 > /sys/class/gpio/export
write: Device or resource busy

Since this patch uses the standard gpiod_get(), would the kernel return an EBUSY error during the probe because those regulators already have the lock? If so, does the driver just get a NULL descriptor and skip the reset logic?

I have only managed to get the HC4 to reboot successfully by using a 'total hack' that bypasses these ownership checks. It uses hardcoded global IDs to hammer the physical reset at the last millisecond, which was for me the only way to kick the SD card back to life on this board.
Here is a link to my hack, which is Odroid HC4 specific. https://github.com/mschirrmeister/PKGBUILDs/blob/main/core/linux-aarch64-msc-rc/0002-driver-power-meson64-reset.patch

[pyavitz]

I tested this updated 7.1 patch on the Odroid-HC4 (SM1), but unfortunately, the SD card still is not being detected after a reboot. Is it possible there is a GPIO ownership conflict on this specific board that prevents the driver from initializing?

I peeked at the meson64-reboot node in the Device Tree and cross-referenced it with the running system. For example, sd-vqsw targets Pin 6, but my /sys/kernel/debug/gpio shows Pin 6 is already claimed by an always-on regulator:

gpiochip1: 15 GPIOs, parent: platform/ff800000.bus:pinctrl@14, aobus-banks:
 gpio-3   (                    |regulator-tflash-vdd) out hi
 gpio-6   (                    |TF_IO               ) out hi 

Trying to manually interact with the pin shows a deadlock:

echo 603 > /sys/class/gpio/export
write: Device or resource busy

Since this patch uses the standard gpiod_get(), would the kernel return an EBUSY error during the probe because those regulators already have the lock? If so, does the driver just get a NULL descriptor and skip the reset logic?

I have only managed to get the HC4 to reboot successfully by using a 'total hack' that bypasses these ownership checks. It uses hardcoded global IDs to hammer the physical reset at the last millisecond, which was for me the only way to kick the SD card back to life on this board. Here is a link to my hack, which is Odroid HC4 specific. https://github.com/mschirrmeister/PKGBUILDs/blob/main/core/linux-aarch64-msc-rc/0002-driver-power-meson64-reset.patch

Concerning this patch. As far as I know, the patch is based on a driver used in an old AML vendor kernel (4.9). tobetter at some point forward ported it and from there its been tweaked by about 4 other people including myself and now AI.

As for the C4/HC4 not resetting properly when rebooting via SD card, in my testing this appears to be related to u-boot. When using anything above v2024.10 this happens. I guess I never noticed as my C4 has been running for several years now off eMMC and although I have flashed newer versions of u-boot to it, I never bothered checking SD card reboot functionality.

Long story short; When using v2025.01 and up, the unit doesn't reset properly. When on v2024.10 it works as it should on the C4.

Can you test if this is also the case for the HC4?

[mschirrmeister]

@pyavitz You mean that I do a test with an older u-boot version? I can definitely try to do that.
Right now I am running u-boot 2025.10.

[pyavitz]

@pyavitz You mean that I do a test with an older u-boot version? I can definitely try to do that. Right now I am running u-boot 2025.10.

Yes. Sorry that wasn't clear.

[mschirrmeister]

I just build a u-boot 2024.10 and tried to boot the HC4. This u-boot version did not detect the sdcard at all.

I am now thinking if I build a hack for the HC4 on top of your patch or if I do a patch for a power reset in u-boot.

[pyavitz]

I just build a u-boot 2024.10 and tried to boot the HC4. This u-boot version did not detect the sdcard at all.

I am now thinking if I build a hack for the HC4 on top of your patch or if I do a patch for a power reset in u-boot.

How are you flashing u-boot? Also is this with the posted patch or ur modded one? On my end I tested it with both 7.1-rc (using the one above) and 6.18.y (using the original) and the results were the same.

As for flashing u-boot. There are really two ways to flash the bins, which isn't something Armbian considers.

eMMC:
sudo dd if=u-boot.bin of=/dev/mmcblkX bs=512 seek=1

SDCARD:
sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=1 count=442
sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1

Flashing the bins correctly is really important. An example of this in Armbian is the gateway-gz80x, which only has an eMMC. If using the SD binary, the unit won't boot at all. The HC4 has no eMMC, but does have an SPI. I would think, like the N2, one would want to write the u-boot.bin (not sd.bin) to the SPI. Unfortunately I don't have this unit (HC4) and don't know much about it beyond the basics.

Anyway, it is something to consider.

EDIT: Because it as no eMMC, maybe the SPI would require the sd.bin in this case? Because I don't have the unit, I can't run tests and I wouldn't want you to brick anything, so be careful.

[mschirrmeister]

I flash u-boot like this. Which should be fine, since I do not use the sd version.

dd if=/boot/u-boot.bin of=/dev/mmcblk0 conv=fsync,notrunc bs=512 seek=1

My SPI is empty. So far all the 2025 or 2026 u-boot versions I used, boot fine when u-boot is only flashed to the sdcard.

My test was with your patch from above on the 7.1-rc2 kernel.

For not detecting the sdcard with u-boot 2024.10, I should have been more precise. The SoC itself could see and read from the sdcard, but u-boot could not. mmc info showed nothing. It even does not show with power off/on. So it should be kernel patch unrelated.
No idea of this older u-boot needs something special for the HC4.

[pyavitz]

@mschirrmeister

Try flashing the SD card this way

sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblk0 conv=fsync bs=1 count=442
sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1

[pyavitz]

@mschirrmeister

Anyway. If your patch works and it doesn't effect other units, I'm fine with it being used instead of the one submitted.

Just about all the SM1 and G12 units require the patch for proper power down and reset.