mdrmdr

A long time ago, that I started the question, but a few days ago, I started again to solve it. And with the help of several AI, I found a working solution. This is the working overlay: /dts-v1/; /plugin/; /* * NanoPI Neo2 H5 - OTG USB with switchable VBUS * Allows SD-Card as USB device on OTG port with GPIO-controlled power * * Key points: * - fragment 0: dr_mode "otg" enables dual-role (host+device detection) * - fragment 1: Removing usb0_id_det-gpios prevents "External vbus detected" error * - fragment 2: Removing gpio property from regulator keeps GPIO 354 (PR2) free for manual control * - fragment 3: GPIO 354 is controlled via usb.sh script (echo 1/0 to /sys/class/gpio/gpio354/value) * * GPIO 354 (PR2) state: * 1 = VBUS ON (USB device recognized) * 0 = VBUS OFF (USB device disconnected) */ / { compatible = "allwinner,sun50i-h5"; fragment@0 { target = <&usb_otg>; __overlay__ { dr_mode = "otg"; status = "okay"; }; }; fragment@1 { target = <&usbphy>; __overlay__ { usb0_id_det-gpios; }; }; fragment@2 { target-path = "/usb0-vbus"; __overlay__ { gpio; status = "okay"; }; }; fragment@3 { target = <&r_pio>; __overlay__ { usb0_vbus_pin: usb0_vbus_pin { pins = "PR2"; function = "gpio_out"; output-high; }; }; }; }; This allows the standard GPIO controls using sysfs in /sys/class/gpio. I'm using the kernel Linux nanopineo2 6.6.75-current-sunxi64 on Armbian 25.11.2 bookworm (32 bit userland). Hope this helps everybody trying to achive the same 😉

May be a small step: This is the overlay I use on both, H3 and H5 systems: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3", "allwinner,sun50i-h5"; fragment@0 { target-path = "/"; __overlay__ { soc { usb@1c19000 { dr_mode = "host"; }; }; usb0-vbus { #status = "okay"; status = "disabled"; }; }; }; }; For H3, I have set status for usb0-vbus to okay, for H5 to disabled. If its okay for the H5, power is on after boot, device (SD card) is usable (see below) but I cannot control power. Now, when disabled, I see following on the H5 system: The proper GPIO 354 file is seen in /sys/class/gpio/. I know that this is the old legacy way of controlling GPIO's on the new kernels. But it works perfectly well on the H3 with the same kernel revision, just 32 bit instead of 64 bit on the H5 I can export it and then echo 1 or 0 to it which actually toggles power (can see that on the blue light of the micro SD adapter for the micro USB port) But, usb0-vbus=disabled seems to disable the whole system USB, as for example lsusb shows nothing anymore and therefore lsblk does not show the device So, nice try, but not successful. I'll continue research the next days. The good thing is, that the H5 is a pure test device 😉

Thanks for the information and the links. I'll dive into it the next days... Yes, the part in the board schematics which controls the chip to power the OTG micro USB port is 100% identical between a NanoPi Neo and a NanoPi Neo2. Same GPIO pin on the SOC. The strange thing is, that the used Kernel would support to enable the sysfs "export" of a GPIO number from userspace: $ zcat /proc/config.gz | grep CONFIG_GPIO_SYSFS CONFIG_GPIO_SYSFS=y I analyzed further the diffs of the device trees and found below (excerpt again) line marked with ** **, which is not in the H3 device tree. The usb0-vbus def is in the H3 tree as well, but not referenced. Tomorrow I'll create an overlay which sets the status of usb0-vbus to "disabled" (as I just read that delete does not exist). Maybe it works 🙃 phy@1c19400 { ** usb0_vbus-supply = <0x19>; ** usb0-vbus { phandle = <0x19>;

Hi, I'm using Armbian 24.11.1 bookworm with a V6.6.62 64 bit Kernel on a NanoPi Neo2. To debug, I have a UART/Serial-to-USB connector attached. Other end is on a Windows 11 box where I use Putty. The setup works fine with one minor issue. During the print of the boot messages, suddenly the printed line width of lines with [ <status> ] is limited 70 columns. It starts shortly after the Welcome to Armbian 24.11.1 bookworm! message and a "…" character is used to shorten the lines. This part has normal line length: Welcome to Armbian 24.11.1 bookworm! [ 4.922261] systemd[1]: Hostname set to <nanopineo>. [ 5.680204] systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6. [ 5.689209] systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6. [ 6.078395] systemd[1]: Queued start job for default target graphical.target. [ 6.107963] systemd[1]: Created slice system-getty.slice - Slice /system/getty. [ OK ] Created slice system-getty.slice - Slice /system/getty. [ 6.137033] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe. From the next output line on, most lines with [ OK ] are shortened with "…": [ OK ] Created slice system-modpr…lice - Slice /system/modprobe. [ 6.165124] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. [ OK ] Created slice system-seria… - Slice /system/serial-getty. [ 6.191931] systemd[1]: Created slice user.slice - User and Session Slice. [ OK ] Created slice user.slice - User and Session Slice. [ 6.218740] systemd[1]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch. [ OK ] Started systemd-ask-passwo…quests to Console Directory Watch. What setting avoids this and allows the print of the full line with line wrap if too long? I'd be already happy it it would be the same behavior as after login, where the line width as defined in Putty (120 characters) is used. Is this just a general limitation of a UART console?

One possible essential difference from cat /sys/kernel/debug/gpio is this: From NanoPi Neo (H3/32bit) gpiochip1: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-354 ( |sysfs ) out hi gpio-355 ( |k1 ) in hi IRQ ACTIVE LOW gpio-358 ( |vdd-cpux ) out lo From NanoPi Neo2 (H5/64bit) gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-354 ( |usb0-vbus ) out hi gpio-358 ( |vdd-cpux ) out lo gpio-362 ( |nanopi:red:pwr ) out hi I think this shows that indeed on the H5, GPIO 354 is occupied by a driver while on the H3 not. Guess this is the reason, that on the H3 echo to /sys/class/gpio/gpio354/value is possible and on H5 not. Who knows how to revert the (default) setting from driver to "sysfs"?

The relevant device tree parts are more or less equal: From NanoPi Neo (H3/32bit) usb_otg = "/soc/usb@1c19000"; usb@1c19000 { clocks = <0x03 0x20>; compatible = "allwinner,sun8i-h3-musb"; dr_mode = "host"; extcon = <0x19 0x00>; interrupt-names = "mc"; interrupts = <0x00 0x47 0x04>; phandle = <0x54>; phy-names = "usb"; phys = <0x19 0x00>; reg = <0x1c19000 0x400>; resets = <0x03 0x11>; status = "okay"; }; usb0-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x15 0x01 0x09 0x00>; phandle = <0x89>; regulator-max-microvolt = <0x4c4b40>; regulator-min-microvolt = <0x4c4b40>; regulator-name = "usb0-vbus"; status = "okay"; }; From NanoPi Neo2 (H5/64bit) usb_otg = "/soc/usb@1c19000"; usb@1c19000 { clocks = <0x03 0x20>; compatible = "allwinner,sun8i-h3-musb"; dr_mode = "host"; extcon = <0x18 0x00>; interrupt-names = "mc"; interrupts = <0x00 0x47 0x04>; phandle = <0x52>; phy-names = "usb"; phys = <0x18 0x00>; reg = <0x1c19000 0x400>; resets = <0x03 0x11>; status = "okay"; }; usb0-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x42 0x00 0x02 0x00>; phandle = <0x19>; regulator-max-microvolt = <0x4c4b40>; regulator-min-microvolt = <0x4c4b40>; regulator-name = "usb0-vbus"; status = "okay"; }; Also the "modern" way of setting the relevant GPIO fails: $ gpiodetect gpiochip0 [1f02c00.pinctrl] (32 lines) gpiochip1 [1c20800.pinctrl] (224 lines) $ gpioinfo gpiochip0 |head -4 gpiochip0 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed "usb0-vbus" output active-high [used] $ gpioset --mode=wait 1f02c00.pinctrl 2=0 gpioset: error setting the GPIO line values: Device or resource busy Somewhere I read, that possibly a driver grabbed the GPIO and therefore its locked. How do I find the driver? It might be a solution to black-list it in /etc/modprobe.d/blacklist-nanopineo.conf

Therefore I wrote "excerpt" in my post. The used dts of course has all required parts and compiles fine... I'll do tonight. Thanks for the idea,

Hi, i could control the OTG micro USB port power on my NanoPi Neo (H3) by exporting and writing to GPIO 354 (line 2 of GPIO chip with base 352) I'm using Kernel V6.6.62 and I created a tiny device tree overlay defining. Excerpt below: usb@1c19000 { dr_mode = "host" } usb0-vbus { status = "okay" } This works fine! For test purposes, I switched to a NanoPi Neo2 (H5) with Kernel 6.6.62 (64 bit). Here, the OTG port is powered on and is usable by default without any overlay. But the on/off control does not work anymore. All attempts to export GPIO 354 give "write error: Device or resource busy". Schematics show no circuit difference in controlling the OTG power. In both cases its the same pin name on H3 and H5. The new GPIO handling of newer kernels cannot be the reason, as I use the same kernel versions on H3 and H5 (beside bit width). Any idea whats wrong and how I can again switch on/off OTG power?