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.