Odroid N2 | GPIO cannot be used

[keypunch416]

Creating a bug report/issue

Required Information

• DietPi version | 8.6.1
• Distro version | bullseye
• Kernel version | Linux DietPi 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
• SBC model | Odroid N2 (aarch64) (N2+ 4GB)
• Power supply used | ALLPOWER 15VDC/4A
• SD card used | 32GB Kingston CANVAS Select Plus MicroSD 100MB/s A1

Additional Information (if applicable)

• Software title | gpiod V1.6.2
• Was the software title installed freshly or updated/migrated? Freshly installed
• Can this issue be replicated on a fresh installation of DietPi? Yes
• Bug report ID | N/A

Steps to reproduce

1. apt install gpiod
2. sudo gpioinfo 0
3. sudo gpioget 0 88
4. sudo gpioget 0 77
5. sudo gpioget 0 76
6. sudo gpioget 0 85
7. sudo gpioget 0 84
8. sudo gpioget 0 495
9. sudo gpioget 0 492
10. sudo gpioget 0 479

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.pdf
• sudo gpioget 0 88 should return state value of GPIO 88 as does not
• sudo gpioget 0 85 should return state value of GPIO 85 as does not
• sudo gpioget 0 84 should return state value of GPIO 84 as does correctly
• sudo gpioget 0 76 should return state value of GPIO 76 as does correctly
• sudo gpioget 0 77 should return state value of GPIO 77 as does correctly
• sudo gpioget 0 495 should return state value of GPIO 495 as does not
• sudo gpioget 0 492 should return state value of GPIO 492 as does not
• sudo gpioget 0 479 should return state value of GPIO 479 as does not

Actual behaviour

• sudo gpioinfo 0 only lists to GPIO 84
• sudo 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 84
• sudo gpioget 0 77 works returning state value of GPIO 77
• sudo gpioget 0 76 works returning state value of GPIO 76
• sudo 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

• The script written to access three GPIO pins via GPIOD (gpioset and gpioget) works just fine on Raspberry Pi where the GPIOs used are: GPIOChip=0 UPSOnlineStatePin=27 UPSPiStatePin=18 UPSPowerStatePin=17
• which should map to on Odriod N2+ per noted link/pdf: GPIOChip=0 UPSOnlineStatePin=480 UPSPiStatePin=492 UPSPowerStatePin=479

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.

[keypunch416]

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.

[keypunch416]

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

[MichaIng]

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.

[keypunch416]

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.

[keypunch416]

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.

[keypunch416]

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.

[MichaIng]

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.

[keypunch416]

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.

[MichaIng]

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.

[keypunch416]

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.

[MichaIng]

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 😉.

[keypunch416]

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.

[keypunch416]

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.

[keypunch416]

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 

[keypunch416]

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:~ $ 

[keypunch416]

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:~ $

[MichaIng]

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.:

• https://forum.odroid.com/viewtopic.php?t=40322
• https://forum.odroid.com/viewtopic.php?t=36696

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.