Open keypunch416 opened 2 years ago
I just updated initial entry and title for issue. For reasons unknown until now and for last two days the N2 link on link referenced in issue was sending one to the C1 entry not aware there was a specific N1, et al points on the page. I will say I was confused the N2 link sent to the C1 part of page consistently last two days and up until created this issue.
I added related tests that already had same results as shown in the attached console log so I will not provide another sample console log as added GPIOs will fail just like GPIO 85 has. As FYI due to the N2 link pointing to C1 my code was using the prior value assignments I have updated to what should be correct N2 GPIOs after discovering the now different page link behavious.
I decided to try to display GPIO values via cat commands as shown in https://wiki.odroid.com/odroid-n2/application_note/gpio/enhancement_40pins. Even GPIO value that worked with gpioget failed:
cat /sys/class/gpio/gpio477/value cat: /sys/class/gpio/gpio477/value: No such file or directory
cat /sys/class/gpio/gpio84/value cat: /sys/class/gpio/gpio84/value: No such file or directory
cat /sys/class/gpio/gpio80/value cat: /sys/class/gpio/gpio80/value: No such file or directory
The sysfs GPIO API ia deprecated in favour of libgpio, but AFAIK Armbian is enabling it again with a future kernel release.
Are you sure that the missing pins are not reserved by other interfaces like UART, I2C or so? I'll have a look when I'm home.
I am sure the pins I want to access are not reserved. I did not mention in log I tried to read the Blue LED and Fan pins via gpioget for each pin and gpioget returned unable to do so as reserved Likewise gpioinfo shows this and alot a few other pins that are reserved because they are being used by other processes. The reserved in use is consistent with my experience with gpiod on Pi is as expected. The script code I wrote for the Pi using gpiod has worked flawless for months whereas the sysfs version was temperamental.
In as far as accessing via depreciated sysfs method I rather not use sysfs. First because with kernels that sysfs was enabled there were a number of downsides even before I discovered gpiod. Once I implemented what I needed with gpiod it was so much cleaner and stable than with sysfs. Second, is no matter which approach is used the issue is the gpio pins/numbering scheme that at least the Odroids use has to work with both gpiod and sysfs. I am no expert, but I find it amazing I be only or first one to report such issues of gpio mapping. In my opinion I really think best to not add sysfs back into kernels and just address the gpiod issues for best long term compatibility and the extra duplication of time, keeping sysfs and gpiod in sync for gpio mapping. Far easier and less time consuming as well as forward going consistency to focus on gpiod and not backport maintaining what is a depreciated kernel interface that will likely be more and more difficult to keep maintaining as time passes.
I happened ny pure chance on very unrelated search to across this link (as happens often enough over years) https://github.com/hardkernel/wiringPi/tree/master/pins that covers a few Odriod devices.
The N2 specific GPIO definitions are in https://github.com/hardkernel/wiringPi/blob/master/pins/odroid_n2.tex.
This would suggest that gpiod is lacking such board specific GPIO definitions.
Some sort of related searching re /sys/class/gpio/gpiochip427 (seems to be the 40 pin header on N2) found this link https://archive.fosdem.org/2018/schedule/event/new_gpio_interface_for_linux/ that states:
Since linux 4.8 the GPIO sysfs interface is deprecated. Due to its many drawbacks and bad design decisions a new user space interface has been implemented in the form of the GPIO character device which is now the preferred method of interaction with GPIOs which can't otherwise be serviced by a kernel driver. The character device brings in many new interesting features such as: polling for line events, finding GPIO chips and lines by name, changing & reading the values of multiple lines with a single ioctl (one context switch) and many more. In this presentation Bartosz will showcase the new features of the GPIO UAPI, discuss the current state of libgpiod (user space tools for using the character device) and tell you why it's beneficial to switch to the new interface.
Ths link noted has links to slides and mp4 about this as well.
Jep WiringPi is an alternative. On Odroids we pull sources from the Hardkernel fork you linked, to have board specifics included. On Odroid M1 it even uses libgpio as backend, leaving the gpio
command only as frontend without actual WiringPi being used 😄.
Even that the sysfs interface is deprecated, it doesn't hurt to leave it enabled. Some older scripts by manufacturers for LCD support and such still use it, and it doesn't conflict with libgpio, just leaves another option open. However, not on us to decide, but on Armbian, since we use their kernel for Odroids.
LED and fan pins are btw still regular GPIO, while enabling UART/I2C/SPI and such disables the common GPIO features on those pins, if I'm not mistaken. Here is the mapping btw: https://wiki.odroid.com/odroid-n2/hardware/expansion_connectors
Is it that one needs to skip the leading 4
when passing the GPIO number, e.g. sudo gpioget 0 95
instead of sudo gpioget 0 495
? GPIO (4)88 is btw used for UART0 by default and GPIO (4)85 for SPI0, so this might be the reason that libgpio cannot access them.
Heading over to your SPI issue now.
LED and power GPIO show as "[used] when run gpioinfo as would, UARTs, I1C and SPI if enabled and not is any were not enabled.
gpioinfo fron the N2+:
gpiochip0 - 85 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed "PHY reset" output active-low [used open-drain] line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed "usb-hub-reset" output active-high [used] line 21: unnamed "regulator-hub_5v" output active-high [used] line 22: unnamed "regulator-usb_pwr_en" output active-high [used] line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high line 32: unnamed unused input active-high line 33: unnamed unused input active-high line 34: unnamed unused input active-high line 35: unnamed unused input active-high line 36: unnamed unused input active-high line 37: unnamed "reset" output active-low [used] line 38: unnamed unused input active-high line 39: unnamed unused input active-high line 40: unnamed unused input active-high line 41: unnamed unused input active-high line 42: unnamed unused input active-high line 43: unnamed unused input active-high line 44: unnamed unused input active-high line 45: unnamed unused input active-high line 46: unnamed unused input active-high line 47: unnamed "cd" input active-low [used] line 48: unnamed unused input active-high line 49: "PIN_44" unused input active-high line 50: "PIN_46" unused input active-high line 51: "PIN_45" unused input active-high line 52: "PIN_47" unused input active-high line 53: "PIN_26" unused input active-high line 54: unnamed unused input active-high line 55: unnamed unused input active-high line 56: unnamed unused input active-high line 57: unnamed unused input active-high line 58: unnamed unused input active-high line 59: unnamed unused input active-high line 60: "PIN_42" unused input active-high line 61: "PIN_32" unused input active-high line 62: "PIN_7" unused input active-high line 63: "PIN_27" unused input active-high line 64: "PIN_28" unused input active-high line 65: "PIN_16" unused input active-high line 66: "PIN_18" unused input active-high line 67: "PIN_22" unused input active-high line 68: "PIN_11" "power" input active-low [used] line 69: "PIN_13" unused input active-high line 70: "PIN_33" unused input active-high line 71: "PIN_35" unused input active-high line 72: "PIN_15" unused input active-high line 73: "PIN_19" unused input active-high line 74: "PIN_21" unused input active-high line 75: "PIN_24" unused input active-high line 76: "PIN_23" unused input active-high line 77: "PIN_8" unused input active-high line 78: "PIN_10" unused input active-high line 79: "PIN_29" unused input active-high line 80: "PIN_31" unused input active-high line 81: "PIN_12" unused input active-high line 82: "PIN_3" unused input active-high line 83: "PIN_5" unused input active-high line 84: "PIN_36" unused input active-high gpiochip1 - 15 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed "enable" output active-high [used] line 3: unnamed unused input active-high line 4: unnamed unused output active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed "regulator-tflash_vdd" output active-high [used] line 9: unnamed "TF_IO" output active-high [used] line 10: unnamed "gpio-fan" output active-high [used] line 11: unnamed "n2:blue" output active-high [used] line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high
It would be my opinion that the "PIN"s indicated in comments are not correct for N2/N2+.
The dropping the 4 from the pin number as you suggested will not work for various reasons. This includes still doing so results above the GPIO 84 current limit I have demonstrated. I strong believe dropping the 4 would not result in correct mapping for the N2.
The hardkernel link you provided I had never found in my search, but is consistent with the link and PDF of like I provided. The difference being the link I provided shows many Odroids and not just the N2. I know it seems odd for GPIO numbers to be in 4xx range, but the WiringPi link I provided in my last comment bears out there are 4xx GPIO numbers which is consistent with the hardkernel link you provided and hardkernel link I had provided.
I am not a kernel developer, but suffice to say I can nose about an make sense of some elements of the code at times and the overall design of source tree structure. I started in assembler for many years on compilers, sysgens, and operating systems (know known as kernels) where all such code was only written in assembler. Back in day where machines had real iron core memory. I found a kernel pinctrl directory and for sure found the Pi GPIO definitions as I know and have used with gpioinfo, gpiofind, gpioget, and gpioset. I did find one pinctrl definition that went up to GPIO 185 which might be for one type of Odroid, but if not clearly demonstrates tehre are processors/boards that have very high GPIO numbers. I have not been able to figure out if there are any Odriod definitions for sure and to what extent including one that may or may not be related to ARM processor N2 uses.
Your point of sysfs can co-exist with gpiod is of course correct and rational. I just feel gpiod is so much cleaner than sysfs and hence gpio may be best to focus on as I have feeling sysfs may not support GPIOs like the N2 and other SBCs have. That said for sure GPIOs such as N2+ uses sysfs show as:
ls -ls /sys/class/gpio/ total 0 0 --w------- 1 root root 4096 Jan 1 1970 export 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip412 -> ../../devices/platform/soc/ff800000.bus/ff800000.sys-ctrl/ff800000.sys-ctrl:pinctrl@14/gpio/gpiochip412 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip427 -> ../../devices/platform/soc/ff600000.bus/ff634400.bus/ff634400.bus:pinctrl@40/gpio/gpiochip427 0 --w------- 1 root root 4096 Jan 1 1970 unexport
ls -ls /sys/class/gpio/gpiochip412 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip412 -> ../../devices/platform/soc/ff800000.bus/ff800000.sys-ctrl/ff800000.sys-ctrl:pinctrl@14/gpio/gpiochip412
ls -ls /sys/class/gpio/gpiochip427 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip427 -> ../../devices/platform/soc/ff600000.bus/ff634400.bus/ff634400.bus:pinctrl@40/gpio/gpiochip427
ls -ls /dev/gpiochip0 0 crw------- 1 root root 254, 0 Mar 20 19:55 /dev/gpiochip0
If you look carefully gpiochip427 has a @40 suggesting this is the 40 pin GPIO header on N2+ and no clue if uses pin numbers 1-40 or "some other" pin numbering mapping. A mapping I assume in many ways is still dependent on kernel if and how the kernel may define.
My sense is to large extent or not at all are the Odroid and many other SBCs like Orange, NanoPi, Rock, et al GPIO pins defined in the kernel which sadly means others having to create and patch in each time to the Linux kernel. Why the Linux Kernel maintainers do not add these GPIO pin definitions in I have no clue as this sort of thing is static for each board/processor and does not change. Also seems once in an easy incremental to add in new processor/board with little effort even if someone does the coding work I suspect the Kernel Maintainers would not accept such patches in sadly and all too often in past as well never or only after years of pressure.
Still I have not found the kernel code or directory for sure to even know where I might be able to start to create the N2 GPIO mapping for kernel.
You are right, the lines reported by libgpio don't seem to be related to the GPIO numbers at all.
I enabled I2CA and couldn't see a difference in what gpioinfo
reports. So it seems like one needs to figure out with libgpio line of which device refers to which GPIO. Hardkernel wiki (and also WiringPi source code) shows the differentiation between GPIOX and GPIOA, which likely refer to gpio0 and gpio1 of libgpio, but numbers (also max) do not match either.
So either testing them trough or using WiringPi seem to be a solution.
You may not be aware, but WiringPi is basically wrapper to sysfs. Ego same issue if one tries to use CLI to sysfs WRT N2 and other SBCs with alternate or as in case of N2 much higher GPIO numbering schemas.
If you have any idea of what Linux Kernel file I could use as basic for creating the N2 pins for Linux Kernel that then hope gpiod could pick up when run I be happy to do the editing to create.
You may not be aware, but WiringPi is basically wrapper to sysfs.
I wasn't, though I could have guessed. Makes sense that Hardkernel moved it to libgpio backend for Odroid M1, which obviously is sufficiently well supported by mainline kernel, finally.
If you have any idea of what Linux Kernel file I could use as basic for creating the N2 pins for Linux Kernel that then hope gpiod could pick up when run I be happy to do the editing to create.
If it was so easy, it would be in mainline Linux already. We can try "next" branch Linux 5.15. I'll give you the instructions tomorrow, need to sleep now 😉.
As I mentioned GPIO has worked so much better than sysfs and really all one is doing is instead of using a cli command to sysfs one is using a gpiod command instead.
There is no need for any 5.15 kernel instructions as the pinctrl I was looking in the Linux Kernel source was for 5.19.
Easy is not issue in adding, it is if Kernel developers want to add and if someone has patch to add will Linux Kernel developers accept/add. Base on my long given up attempts with the Linux Kernel developers I gave up on much more simple and/or still very serious issues in the Linux Kernel.
You have a good restful sleep. Thanks for the replies and thoughts.
As FYI why this is important issue is the UPS HAT is controlled and status of power/UPS running is via GPIO commands which is used to keep seismometer logging when there are those second or two power blips and for couple hours when power fails once I purchase large capacity batteries. The scrip provided used sysfs, but just too many issues with sysfs so I tried gpiod and was so clean. After that I created much better script from scratch that is rock stable not just how I write and design code, but because of gpiod. Great that the M1 is using gpiod. M1 is consideration for these seismic application needs in event 4Gb of N2+ is not enough or too tight. For start I will need at least three of N2+ or M1. I have three N2+ and frankly so much better in so many ways to Raspberry Pi and for sure so much better than RPi4B. It has taken almost a year for me to secure the N2+ due to supply chain issues and for while the USD/CAD exchange rates were just too insane for someone like me that has been on very limited fixed income disability for over 10 years (not IT career related) where those insane exchange rates are significant.
Have a wonderful restful sleep. I hope not too hot/humid were you are. In Toronto a week long heat alert just ended, but hints of will occur again in few days. Humidity really bad that comes from Gulf of Mexico.
Various combinations of GPIO input pins tried to change state of return 0 as successful but in fact do not change GPIO state. For example (of various input GPIO pins tried):
dietpi@DietPi:~$ sudo gpioget 0 18 ; echo $?
1
0
dietpi@DietPi:~$ sudo gpioset 0 18=0 ; echo $?
0
sbc@DietPi:~$ sudo gpioget 0 18 ; echo $?
1
0
dietpi@DietPi:~$
This means aside from mapping one cannot actual use GPIO pins not can any programs et al use GPIO pins let alone mapping issues do not match N2+ pin number, N2+ pinout names, nor the physical pin number.
Some Additional Testing:
Manjaro-ARM same issues with gpioset and gpioget as DietPi 8.6.1.
Official Hardkernel 22.04 same issues with gpioset and gpioget as DietPi 8.6.1, but gpio <chip name/number> inverted meaning what was on <chip name/number> 0 is on 1 and what was on <chip name/number> 1 is on 0, one additional line both <chip name/number> so go to 85 and not 84, and to 15 and not 14, and no "Pin*" descriptions for any of the pins
Sun Jul 31 22:13:40 UTC 2022
'Linux odroid 4.9.312-22 #1 SMP PREEMPT Mon Jun 20 17:12:03 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux'
Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy
gpiochip0 - 16 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed "line_mute" output active-high [used]
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed unused input active-high
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed "amlsd" output active-high [used]
line 10: unnamed "pwm" output active-high [used]
line 11: unnamed "?" output active-high [used]
line 12: unnamed unused input active-high
line 13: unnamed unused input active-high
line 14: unnamed unused input active-high
line 15: unnamed unused input active-high
gpiochip1 - 86 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed unused input active-high
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed unused input active-high
line 10: unnamed unused input active-high
line 11: unnamed unused input active-high
line 12: unnamed unused input active-high
line 13: unnamed unused input active-high
line 14: unnamed unused input active-high
line 15: unnamed unused input active-high
line 16: unnamed unused input active-high
line 17: unnamed unused input active-high
line 18: unnamed unused input active-high
line 19: unnamed unused input active-high
line 20: unnamed unused input active-high
line 21: unnamed "usb_hub" output active-high [used]
line 22: unnamed "usb_hub_en" output active-high [used]
line 23: unnamed "ffe09080.usb3phy" output active-high [used]
line 24: unnamed unused input active-high
line 25: unnamed unused input active-high
line 26: unnamed unused input active-high
line 27: unnamed unused input active-high
line 28: unnamed unused input active-high
line 29: unnamed unused output active-high
line 30: unnamed unused input active-high
line 31: unnamed unused input active-high
line 32: unnamed unused input active-high
line 33: unnamed unused input active-high
line 34: unnamed unused input active-high
line 35: unnamed unused input active-high
line 36: unnamed unused input active-high
line 37: unnamed unused input active-high
line 38: unnamed "amlsd" output active-high [used]
line 39: unnamed unused input active-high
line 40: unnamed unused input active-high
line 41: unnamed unused input active-high
line 42: unnamed unused input active-high
line 43: unnamed unused input active-high
line 44: unnamed unused input active-high
line 45: unnamed unused output active-high
line 46: unnamed unused input active-high
line 47: unnamed unused input active-high
line 48: unnamed "amlsd" input active-high [used]
line 49: unnamed unused input active-high
line 50: unnamed unused input active-high
line 51: unnamed unused input active-high
line 52: unnamed unused input active-high
line 53: unnamed unused input active-high
line 54: unnamed unused input active-high
line 55: unnamed unused input active-high
line 56: unnamed unused input active-high
line 57: unnamed unused input active-high
line 58: unnamed unused input active-high
line 59: unnamed unused input active-high
line 60: unnamed unused input active-high
line 61: unnamed unused input active-high
line 62: unnamed unused input active-high
line 63: unnamed unused input active-high
line 64: unnamed unused input active-high
line 65: unnamed unused input active-high
line 66: unnamed unused input active-high
line 67: unnamed unused input active-high
line 68: unnamed unused input active-high
line 69: unnamed unused input active-high
line 70: unnamed unused input active-high
line 71: unnamed unused input active-high
line 72: unnamed unused input active-high
line 73: unnamed unused input active-high
line 74: unnamed unused input active-high
line 75: unnamed unused input active-high
line 76: unnamed "spi0.0" output active-high [used]
line 77: unnamed unused input active-high
line 78: unnamed unused input active-high
line 79: unnamed unused input active-high
line 80: unnamed unused input active-high
line 81: unnamed unused input active-high
line 82: unnamed unused input active-high
line 83: unnamed unused input active-high
line 84: unnamed unused input active-high
line 85: unnamed unused input active-high
By contrast here are results in Raspberry P1 1B+ using gpiod:
sbc@PiUPS:~ $ gpiodetect
gpiochip0 [pinctrl-bcm2835] (54 lines)
sbc@PiUPS:~ $ gpioinfo
gpiochip0 - 54 lines:
line 0: "ID_SDA" unused input active-high
line 1: "ID_SCL" unused input active-high
line 2: "SDA1" unused input active-high
line 3: "SCL1" unused input active-high
line 4: "GPIO_GCLK" unused input active-high
line 5: "GPIO5" unused input active-high
line 6: "GPIO6" unused input active-high
line 7: "SPI_CE1_N" "spi0 CS1" output active-low [used]
line 8: "SPI_CE0_N" "spi0 CS0" output active-low [used]
line 9: "SPI_MISO" unused input active-high
line 10: "SPI_MOSI" unused input active-high
line 11: "SPI_SCLK" unused input active-high
line 12: "GPIO12" unused input active-high
line 13: "GPIO13" unused input active-high
line 14: "TXD0" unused input active-high
line 15: "RXD0" unused input active-high
line 16: "GPIO16" unused input active-high
line 17: "GPIO17" unused input active-high
line 18: "GPIO18" unused input active-high
line 19: "GPIO19" unused input active-high
line 20: "GPIO20" unused input active-high
line 21: "GPIO21" unused input active-high
line 22: "GPIO22" unused input active-high
line 23: "GPIO23" unused input active-high
line 24: "GPIO24" unused input active-high
line 25: "GPIO25" unused input active-high
line 26: "GPIO26" unused input active-high
line 27: "GPIO27" unused input active-high
line 28: "SDA0" unused input active-high
line 29: "SCL0" unused input active-high
line 30: "NC" unused input active-high
line 31: "LAN_RUN" unused output active-high
line 32: "CAM_GPIO1" unused output active-high
line 33: "NC" unused input active-high
line 34: "NC" unused input active-high
line 35: "PWR_LOW_N" "led1" input active-high [used]
line 36: "NC" unused input active-high
line 37: "NC" unused input active-high
line 38: "USB_LIMIT" unused output active-high
line 39: "NC" unused input active-high
line 40: "PWM0_OUT" unused input active-high
line 41: "CAM_GPIO0" "cam1_regulator" output active-high [used]
line 42: "NC" unused input active-high
line 43: "NC" unused input active-high
line 44: "ETH_CLK" unused input active-high
line 45: "PWM1_OUT" unused input active-high
line 46: "HDMI_HPD_N" "hpd" input active-low [used]
line 47: "STATUS_LED" "led0" output active-high [used]
line 48: "SD_CLK_R" unused input active-high
line 49: "SD_CMD_R" unused input active-high
line 50: "SD_DATA0_R" unused input active-high
line 51: "SD_DATA1_R" unused input active-high
line 52: "SD_DATA2_R" unused input active-high
line 53: "SD_DATA3_R" unused input active-high
sbc@PiUPS:~ $
Then one can make code dynamic to pin name and not GPIO line number nor GPIO chip:
sbc@PiUPS:~ $ gpioget $(gpiofind "SDA0") 1 sbc@PiUPS:~ $
Still an issue with recent edge kernel btw:
# uname -a
Linux OdroidN2 6.2.0-rc3-meson64 #22.11.4 SMP PREEMPT Mon Jan 23 21:32:39 UTC 2023 aarch64 GNU/Linux
Also changing GPIO states, also of those with an actual pin name, does not work. Readout of some may even crash the system:
gpioget 1 4
Sadly this is above my knowledge. I guess it requires adjustments to the device tree.
The Odroid forum is a good place to check, e.g.:
These kernel errors are likely related:
Feb 05 17:39:34 OdroidN2 kernel: gpio irq setup: hwirq: 0x3B irqfirst: 0x35 irqlast: 0x3C pin[47]
Feb 05 17:39:34 OdroidN2 kernel: genirq: Setting trigger mode 3 for irq 24 failed (meson_gpio_irq_set_type+0x0/0x68)
If strictly needed, workaround is to downgrade to legacy vendor kernel:
apt install linux-{image,dtb}-legacy-meson64
But create a full disk backup or have the ability to revert symlink to current kernel, in case it does not boot. I haven't tested it.
Creating a bug report/issue
Required Information
Linux DietPi 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
Additional Information (if applicable)
Steps to reproduce
Expected behaviour
sudo gpioinfo 0
should go to at least to at least GPIO 495 per https://wiki.odroid.com/odroid-n2/application_note/gpio/enhancement_40pins " enhancement_of_gpio_pins.pdf" created via icon on page to make PDF of page enhancement_of_gpio_pins.pdfsudo gpioget 0 88
should return state value of GPIO 88 as does notsudo gpioget 0 85
should return state value of GPIO 85 as does notsudo gpioget 0 84
should return state value of GPIO 84 as does correctlysudo gpioget 0 76
should return state value of GPIO 76 as does correctlysudo gpioget 0 77
should return state value of GPIO 77 as does correctlysudo gpioget 0 495
should return state value of GPIO 495 as does notsudo gpioget 0 492
should return state value of GPIO 492 as does notsudo gpioget 0 479
should return state value of GPIO 479 as does notActual behaviour
sudo gpioinfo 0
only lists to GPIO 84sudo gpioget 0 88
fails "gpioget: error reading GPIO values: Invalid argument"sudo gpioget 0 85
fails "gpioget: error reading GPIO values: Invalid argument"sudo gpioget 0 84
works returning state value of GPIO 84sudo gpioget 0 77
works returning state value of GPIO 77sudo gpioget 0 76
works returning state value of GPIO 76sudo gpioget 0 495
fails "gpioget: error reading GPIO values: Invalid argument"sudo gpioget 0 492
fails "gpioget: error reading GPIO values: Invalid argument"sudo gpioget 0 479
fails "gpioget: error reading GPIO values: Invalid argument"Extra details
GPIOD is being used as the echo in/out > /sys/class/gpio approach so often used for many years is depreciated in Linux kernel. GPIOD is considered to going forward method to use.
Console output of tests/results is attached.
DietPI.n2p-gpiod-Bug-20220723-console.txt
gpioinfo --version gpioinfo (libgpiod) v1.6.2 Copyright (C) 2017-2018 Bartosz Golaszewski License: LGPLv2.1 This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.