Hans Kurscheidt
-
Posts
28 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Hans Kurscheidt
-
-
vor 15 Stunden schrieb going:
This problem will not be considered by the armbian maintainers.
I'll try to explain.
This problem relates to the work\development of the kernel gpio subsystem.
The kernel has a corresponding gpio driver for the Raspberry Board.For boards using Allwinner processors, there is no native driver in the kernel yet.
Armbian members are not developers of kernel drivers.
My and your personal interest in the gpio topic and the fact that you and I are discussing it here is relevant only to us.
I will return to development only in late autumn. If my actions are successful. I'll let you know.
But again, this is only a personal initiative.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?
RGDS
hk
-
vor 19 Stunden schrieb usual user:
The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed.
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
-
vor 10 Stunden schrieb schwar3kat:
I've not looked at permissions for gpoid. The file would probably need to be tweaked to cover the device structure.
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!
-
vor 4 Stunden schrieb schwar3kat:
Hans, you are missing a / in front of bin.
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??
-
vor 13 Stunden schrieb usual user:
gpio-event-mon -n gpiochip0 -o 4 -r -f -b 10000 ; shutdown
What & where is gpio-event-mon, and does it use the internal pull-up? And where is the documentation??
-
vor 13 Stunden schrieb going:
Did I understand correctly? Do you need the power off button on this board to work? Is that all?
@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.
-
vor einer Stunde schrieb going:
please explain to me why the existence of the /sys/class/gpio interface is so important
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 -
vor 1 Stunde schrieb schwar3kat:
Armbian has no input into the upstream kernel build.
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 unexportMore 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 -
vor 3 Stunden schrieb schwar3kat:
"select GPIO_CDEV # We need to encourage the new ABI"
... if it would work. Please refer to
-
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.255After 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 29GI 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
-
vor 8 Stunden schrieb schwar3kat:
I am currently looking at restoring the functionality for this build.
Good to know! WiringPi for the OrangePi family has no prominent promoter and gpiod is still in its crude infancy.
-
vor 14 Stunden schrieb schwar3kat:
Hans, It is a kernel deprecation issue.
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)
USB disconnect (Solution)
in Beginners
Posted
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