NanoPi Neo2 V1.1 / how to control OTG port power with GPIO 354?

[mdrmdr]

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?

Edited Thursday at 11:31 AM by mdrmdr

[going]

2 часа назад, mdrmdr сказал:

Schematics show no circuit difference in controlling the OTG power.

But dtb may have differences.
I mean the one that was used on a working device.
Extract for both cases and compare.
 

dtc --sort -I fs -O dts  /sys/firmware/devicetree/base > dts-out.txt

 

Maybe this will give you a clue.

[robertoj]

I have never seen a dts so small.

 

Usually, they have several "fragment" codeblocks.

[mdrmdr]

vor einer Stunde schrieb robertoj:

I have never seen a dts so small.

Therefore I wrote "excerpt" in my post. The used dts of course has all required parts and compiles fine...

 

vor 5 Stunden schrieb going:

Extract for both cases and compare.

I'll do tonight. Thanks for the idea,

[mdrmdr]

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

[mdrmdr]

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"?

[robertoj]

For another orange pi board, someone had success with an official (but old) DTBO:

https://forum.armbian.com/topic/31654-orange-pi-zero-2w/page/2/#findComment-202508

There's a very interesting discussion about GPIO troubleshooting here (and how sysfs is deprecated), I hope it helps:

https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio

 

[going]

6 часов назад, mdrmdr сказал:

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 h5 <-> h3 processors are pin-to-pin compatible.
That is, you can solder h3 and solder h5 to this place.
After modifying the DTS file for the board, you can make it work.
That's the theory.

 

In your case, the difference is probably in the PCB layout.
 

19 часов назад, mdrmdr сказал:

From NanoPi Neo (H3/32bit)

gpio = <0x15 0x01 0x09 0x00>;

19 часов назад, mdrmdr сказал:

NanoPi Neo2 (H5/64bit)

gpio = <0x42 0x00 0x02 0x00>;

 

You'll have to find some kind of workaround.

[mdrmdr]

vor 2 Stunden schrieb robertoj:

For another orange pi board, someone had success with an official (but old) DTBO:

Thanks for the information and the links. I'll dive into it the next days...

 

vor 2 Stunden schrieb going:

The h5 <-> h3 processors are pin-to-pin compatible.

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>;

 

Edited 5 hours ago by mdrmdr