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 Friday at 08:49 PM by mdrmdr

[going]

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

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.

You can also compare the dts after all the patches have been applied in my branch.

sunxi-6.6-rebase

 

If you find that something does not match the circuit board and you can fix it,

then you can post the fixes (git forat-patch -1) directly here or make a pull request on the github.

[mdrmdr]

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 😉

 

Edited 20 hours ago by mdrmdr