Hans Kurscheidt

The internet is full of reports, that USB devices get disconnected at random after some time. Camera or disc-drives, keyboards etc. For me it was a GPS device. The solution is described here https://hamwaves.com/usb.autosuspend/en/ and here https://www.kernel.org/doc/Documentation/usb/power-management.txt

Thank you very much. Its understood and appreciated! However I hope that the old sysfs i/f will stay in place until the issue will be solved.

After this open problem has ended up in "old bug tracker (read only)", I would like to bring this up here again. Could somebody please illuminate my ignorance, how this issue will be treated further? https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/ RGDS hk

This is in fact an excellent idea! the key word is UNIFORM @going: For the time being, gpiod can only handle PIO; why block something very useful for something which does not yet exist (UART etc. func. in gpiod) Today, Users have no chances to find the pin, they are looking for. One has to scroll through 645 pages of chip documentation to understand which logical pin is allocated in which chipset. After this, the user has to crawl through the schematics to understand which SoC-Pin is connected to which Pin-header. Names like con1-xy would make things clear right from the beginning!

its all about these:

Let me more precise; pse follow the following simple recipe w/ gpiod V1.65+ installed: Power up Connect 1 Pin of your choice to GND using a patch wire Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> // rising edge, pull-up, exit after 1 event expected behavior: cmd should "hang" and wait for rising edge @ Pin Pull the wire expected behavior: cmd should exit w/ event and timestamp Reconnect the patch wire to ground, then Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin failure: cmd exits immediately w/ false event and timestamp although there was no rising edge (Pin was wired to GND) Exe the same cmd a 2nd time w/out having touched the wire: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin Now pull the wire expected behavior: cmd should exit w/ event and timestamp Leave the wire open (Pull-up will pull the Pin permanently up Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin failure: cmd exits w/ false event and timestamp although there was no rising edge (Pin was permanently high) all subsequent calls to gpiomon will fail w/ false event (behavior as "Level" Interrupt) The issue is most likely related to initialization problems. Pins can be connected to various points internally in the SoC. UART, I2C, PIO... as well to pull-up/down, Highend/lowend FETS, etc. To do this, an internal microcode needs to be executed in the chip. In many uControllers, the Pin becomes unstable during the execution of the uCode. I expect that upon each execution of the gpiomon cmd, the pin is newly initialized. The new 2nd & ff initializations could lead to a false rising edge flag in the chip register, which will then trigger a spurious interrupt, when enabled. I suggest to consider, writing the chip config registers only after reading them before and in case that the new config would be different, from what was read back, before. Attaching the wire/button to a pin leads to line bouncing effects. The rising edge flag in the SoC may be re-triggered during the ISR execution of the 1st rising edge. The next execution of gpiomon, which will enable interrupts again, will then be trapped by the pending int flag. Enabling interrupts in the SoC PIO should always happen, after making sure that there is no pending int-flag, somewhere. RGDS hk

Hello, again, Nobody feeling responsible for this?? When this issue would be solved, gpiod V. 1.65 +newer could indeed become an acceptable utility replacing the depreciated sysfs feature for future development. RGDS hk

I just changed /dev/gpiochip* to group "gpio" as I did for sysfs, and gpiod now works w/out root priv. Wouldn't it be a good idea to put the rules file for sysfs and /dev/gpiochip* into the normal distro??

Hi Kat, appears to be working. Welcome to Armbian 22.02.1 with Linux 5.15.32-sunxi64 System load: 19% Up time: 0 min Memory usage: 22% of 482M IP: 192.168.1.37 192.168.100.1 CPU temp: 53°C Usage of /: 24% of 29G RX today: 39.5 MiB [ General system configuration (beta): armbian-config ] Last login: Wed Apr 6 11:04:11 2022 from 192.168.1.31 hk@orangepizeroplus:~$ uname -a Linux orangepizeroplus 5.15.32-sunxi64 #trunk.0038 SMP Thu Apr 7 15:18:59 UTC 2022 aarch64 GNU/Linux hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 export lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 unexport hk@orangepizeroplus:~$ echo 6 > /sys/class/gpio/export hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 -rwxrwx--- 1 root gpio 4096 Apr 7 20:59 export lrwxrwxrwx 1 root gpio 0 Apr 7 20:59 gpio6 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip1/gpio/gpio6 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 unexport hk@orangepizeroplus:~$ gpiodetect gpiochip0 Permission denied Segmentation fault hk@orangepizeroplus:~$ sudo gpiodetect [sudo] password for hk: gpiochip0 [1f02c00.pinctrl] (32 lines) gpiochip1 [1c20800.pinctrl] (224 lines) hk@orangepizeroplus:~$ gpio readall +-----+-----+----------+------+-Orange Pi Zero 2-+------+----------+-----+-----+ | H5 | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | H5 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 12 | 8 | SDA.0 | ALT3 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | SCL.0 | ALT3 | 0 | 5 || 6 | | | 0v | | | | 6 | 7 | GPIO.7 | ALT3 | 0 | 7 || 8 | 0 | ALT3 | TxD3 | 15 | 198 | | | | 0v | | | 9 || 10 | 0 | ALT3 | RxD3 | 16 | 199 | | 1 | 0 | RxD2 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1 | 1 | 7 | | 0 | 2 | TxD2 | ALT3 | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | CTS2 | ALT3 | 0 | 15 || 16 | 0 | ALT4 | GPIO.4 | 4 | 19 | | | | 3.3v | | | 17 || 18 | 0 | ALT4 | GPIO.5 | 5 | 18 | | 15 | 12 | MOSI | ALT3 | 0 | 19 || 20 | | | 0v | | | | 16 | 13 | MISO | ALT3 | 0 | 21 || 22 | 0 | ALT3 | RTS2 | 6 | 2 | | 14 | 14 | SCLK | ALT3 | 0 | 23 || 24 | 0 | ALT3 | CE0 | 10 | 13 | | | | 0v | | | 25 || 26 | 0 | ALT3 | GPIO.11 | 11 | 10 | +-----+-----+----------+------+---+---LEDs---+---+------+----------+-----+-----+ | 17 | 30 | STAT-LED | OUT | 0 | 27 || 28 | | | PWR-LED | | | +-----+-----+----------+------+---+-----+----+---+------+----------+-----+-----+ | H5 | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | H5 | +-----+-----+----------+------+-Orange Pi Zero 2-+---+------+---------+-----+--+ hk@orangepizeroplus:~$ gpiod apparently cannot make use of the gpio group permission. WiringPi as usual. I put it onto my "compiler engine" (Visual Studio 2022 CPP cross env w/ OPi0+ as target). I have a few long haul flights in Mai, so I don't want to risk messing things up. Therefore, I will stay w/ 5.10 on my production machine for the next 2 month. How will things move on from here? When and where will this become "regular" instead of nightly? Thank-you very much to you and all the guys in the background (followed discussion on GitHub) for your swift action!!!! Best Regards hk

Dears, I have recently posted several issues wrt. OPi0+. GPIO (sysfs), armbian-config (bug confirmed by Igor), WiFi AP, GPIO event handling. Except for GPIO, where high activity is going on, I cannot find anything in "GitHub-issues" about the other problems, I have raised. I therefore would like to know, what would be the right place to rise issues? Here in the forum, or in GitHub? I mean "issues", not "how tos"

Cannot set internal pull-ups! Moreover I don't want to go on "somebodies" git page to look for solutions, which may be abandoned, tomorrow. If the Debian Kernel makers decide to stop and remove a widely used i/f by surprise, they have the obligation to provide a widely working and well documented new solution for USERS ! I don't see anything like this. Forcing users to search git up&down, retro-engineer code and .h files is no documentation. And distributing a version of e.g. gpiod of 3-4 versions behind is no solution as well!

Holy cow! sorry for this!! Its working now. Thanks!

WRT dtb editing. May be I am old fashioned, but an APP for me is supposed to run on the designed HW "as is" i.e. it has to bring its own capability to configure the necessary i/f at user space, making eventually use of middleware. In my case, I achieve this by using sysfs and WiringPi. Apart from the fact that armbian-config has a bug and edits the wrong dtb, disasembling, editing & recompiling a dtb file is not for the average user and would my App put into the situation, where its not runnable on OPi0+ boards from the shelve, anymore. Or do you think that M$ Office would be so successful, if the users had to go into the BIOS of their MoBo to fiddle around w/ something??

@usual user What & where is gpio-event-mon, and does it use the internal pull-up? And where is the documentation??

@going No! I use the OPi0+ on a PCB as MoBo as an EFIS w/ an Arduino Nano as analogue concentrator and GPIO extender w/ RS232, I2C, SPI, GPIO and a handful of sensors. Shutdown was just 1 function of it, I picked it as example, because its easy. The important issues for me to switch to the new i/f are the ability to use the internal pull-ups, because I don't want to make a new PCB revision w/ external pull-ups and a working event monitoring, which is not the case for gpiod on the OPi0+, as I stated before. The shutdown is initiated electronically w/ a MOSFET and an R/C combination & Optocoupler, where the MOSFET keeps the power 30 secs alive when the avionic switch is pulled off to enable a proper shutdown.

Hi, just go and write in your preferred method a shell script, for a GPIO Pin w/ pull-up and a button, to initiate shutdown, when the button is pressed. In sysfs & WiringPi its about 10 lines of bash; hence I hope I'm asking you not too much. RGDS

Sorry, doesn't work for me. Tried to make it executable, but no cure. Welcome to Armbian 22.02.1 with Linux 5.10.60-sunxi64 System load: 18% Up time: 0 min Memory usage: 26% of 474M IP: 192.168.1.37 192.168.100.1 CPU temp: 57°C Usage of /: 24% of 29G RX today: 111.6 MiB [ 0 security updates available, 37 updates total: apt upgrade ] Last check: 2022-04-05 17:24 Last login: Tue Apr 5 17:24:18 2022 from 192.168.1.31 hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 --w------- 1 root root 4096 Apr 5 17:28 export lrwxrwxrwx 1 root root 0 Apr 5 17:28 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Apr 5 17:28 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 --w------- 1 root root 4096 Apr 5 17:28 unexport hk@orangepizeroplus:~$ cd /sys/class/gpio hk@orangepizeroplus:/sys/class/gpio$ echo 6 >export -bash: export: Permission denied hk@orangepizeroplus:/sys/class/gpio$ cat /etc/udev/rules.d/99-gpio-group.rules SUBSYSTEM=="gpio*", PROGRAM="bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc && chmod -R 770 /sys/devices/platform/soc'" hk@orangepizeroplus:/sys/class/gpio$ ll /etc/udev/rules.d/ total 12 -rw-r--r-- 1 root root 70 Oct 12 17:33 10-wifi-disable-powermanagement.rules -rw-r--r-- 1 root root 3449 Oct 12 17:33 50-usb-realtek-net.rules -rwxr-xr-x 1 root root 285 Apr 5 17:23 99-gpio-group.rules hk@orangepizeroplus:/sys/class/gpio$groups hk tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh i2c gpio

Hi Kat, your effort is highly appreciated! But you can tell'em in my name the following: Depreciating a widely used i/f is BAU, but replacing it w/ something not backwards compatible is already doubtful! Even if it was announced before, just switching it off and forcing a bazillion number of users rewriting their code is NOT AKZEPTABLE! It not just hits the sysfs users, it affects as well the large community of WiringPi users. It is not akzeptable, especially because the new i/f is not widely accepted; most users are not even aware of it. What RPI users think about it, one can read here: https://raspberrypi.stackexchange.com/questions/136479/confusion-with-libgpiod-and-the-gpiod-user-tools there is no alternative to gpiod and no documentation for different levels of expertise the current Debian distributes gpiod 1.3, which is for all practical purposes useless, if you want to do more than just blinking an LED. The current stable version is at 1.6.5. Even the gpiod V 2.0 nightly cannot work, due to kernel-driver issues in the driver for the Allwinner CPUs, as I have stated here: https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/ Hence, most users are left in Limbo! I would at least expect that they create a switch so that old/new can be selectable at user level. That behavior wasn't #Expert, more #Amateur RGDS hk I just powered up my RPI and found that they are still on kernel 5.10; there might ba reason for this! $ uname -a Linux raspberrypi 5.10.103-v7+ #1530 SMP Tue Mar 8 13:02:44 GMT 2022 armv7l GNU/Linux hk@raspberrypi:~ $ ls -l /sys/class/g* /sys/class/gpio: insgesamt 0 --w--w---- 1 root gpio 4096 29. Mär 17:45 export lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip100 -> ../../devices/gpiochip1/gpio/gpiochip100 lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:expgpio/gpio/gpiochip504 --w--w---- 1 root gpio 4096 29. Mär 17:45 unexport More over, compared to OPI/Armbian, pse take note that there is a Group gpio (not root) which solves quite some ACL problems w/ gpio uname -a Linux orangepizeroplus 5.10.60-sunxi64 #21.08.1 SMP Wed Aug 25 18:29:57 UTC 2021 aarch64 GNU/Linux hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 --w------- 1 root root 4096 Jan 1 1970 unexport

... if it would work. Please refer to https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/

Hi, installing a WiFi Hotspot eliminates the wlan0 from the network manager. Files like hostapd, dnsmasq must be edited manually. I have 2 files for hostapd: ll /etc/network/interfaces.d total 8 -rw-r--r-- 1 root root 163 Mar 25 18:55 armbian.ap.nat -rw-r--r-- 1 root root 154 Jan 20 12:16 orig_armbian.ap.nat hk@orangepizeroplus:/etc/dnsmasq.d$ cat /etc/network/interfaces.d/* # armbian NAT hostapd allow-hotplug wlan0 iface wlan0 inet static address 192.168.100.1 netmask 255.255.255.0 network 192.168.100.0 broadcast 192.168.100.255 # armbian NAT hostapd allow-hotplug wlan0 iface wlan0 inet static address 172.24.1.1 netmask 255.255.255.0 network 172.24.1.0 broadcast 172.24.1.255 After boot, both IP addresses here 192.168.100.1 AND 172.24.1.1 appear in the welcome msg: Welcome to Armbian 22.02.1 with Linux 5.10.60-sunxi64 System load: 6% Up time: 6 min Memory usage: 22% of 474M IP: 192.168.0.100 192.168.1.37 192.168.100.1 172.24.1.1 CPU temp: 46°C Usage of /: 24% of 29G I had to delete manually orig_armbian.ap.nat to get rid of the 172.... Is this a feature or a bug? RGDS hk

I am on an OrangePi zero plus H5: Linux orangepizeroplus 5.10.60-sunxi64 #21.08.1 SMP Wed Aug 25 18:29:57 UTC 2021 aarch64 GNU/Linux Editing the dts via armbian-config, the sun50i-h5-orangepi-zero-plus2.dtb is edited and compiled, while the board boots into sun50i-h5-orangepi-zero-plus.dtb -rw-r--r-- 1 root root 31117 Mar 29 16:55 sun50i-h5-orangepi-zero-plus2.dtb -rw-r--r-- 1 root root 31121 Mar 28 16:39 sun50i-h5-orangepi-zero-plus2.dtb.bak -rw-r--r-- 1 root root 31144 Aug 25 2021 sun50i-h5-orangepi-zero-plus.dtb

I cut/paste a related information exchange I had w/ Kent from the gpiod mailing list. The arbian-monitor output is in the attached file. >>>>>>>> I wired a GPIO Pin to GND. Upon the cmd: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> the program exits immediately with 1 event, although there was never a rising edge due to the fix wire to GND. Is this a feature or a bug, and is it reproducible? < Not a feature and not reproducible for me on a Raspberry Pi4 with the setup you describe, so probably a bug specific to your hardware platform, whatever that may be. If it is 100% reproduceable for you, and assuming it is an initialisation issue so you only get the one spurious event, how about using -n2 as a workaround ? Cheers, Kent. > It appears 2b reproduceable 100% on my OrangePi zero+ (Allwinner H5) and using -n2 does the trick, but isn't gpiod not supposed to work on all commercial HW platforms and related kernels, rather then only on RPI?? < gpiod will work on any platform with a supporting kernel. How well depends on the underlying hardware and driver. The RPi4 was merely a counter-example demonstrating that your issue is not universal, using hardware I happen to have readily available. Cheers, Kent. > So if I understand you right, gpiod works on sort of a logical level, while the HW dependend part depends of the kernel driver implementation of the specific HW? < libgpiod is a userspace library and tools to access GPIO lines via the Linux GPIO character device. The actual interfacing to the hardware is performed by the kernel and appropriate drivers for your hardware. As your problem does not exhibit on other hardware, the root cause of your problem probably lies in the driver for your hardware, not in libgpiod nor the gpiolib subsystem of the kernel. But you would need to debug it further to be sure. Cheers, Kent. * Event should be more correct than Interrupt. I made some trial to understand if it is reproduceable, but I have difficulties defining, when it happens. After RESET there is no spurious event. The spurious event appears to happen, when the line was moved: RESET, gpiomon -r -n1 -Bpull-up 1 6 => No event, -> pull line up /down, => event (as expected), gpiomon -r -n1 -Bpull-up 1 6 => false event There might be an issue w/ pending interrupts, when the line is bouncing when pulled up/down. The 2nd gpiodmon cmd might catch one of the pending interrupts. (Just an idea). This would hint to an initialisation problem, that pending line states are not preempted, before the int is attached. If I just let the line go up (by pull-up) and leave it "1", I get continuous false events on every gpiomon... cmd, just like "level interrupts" Kent Gibson and I performed checks independently on our RPIs and we both can confirm that the problem does no occur on the RPI: Linux raspberrypi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux armbian-monitor-U.txt

Good to know! WiringPi for the OrangePi family has no prominent promoter and gpiod is still in its crude infancy.

Yep, I thought about it. You won't make a lot of friends w/ this.

Linux orangepizeroplus 5.15.25-sunxi64 #22.02.1 SMP Sun Feb 27 09:24:04 UTC 2022 aarch64 GNU/Linux. I don't see anymore the /sys/class/gpio... directory. Has this been suppressed or is my filesystem corrupted? The /sys/class/ dir exists w/ a lot of stuff, just gpio is missing! This is duplicated in Discord, but I'm not sure, if it is right there (1st use)