-
-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Odroid N2 | GPIO cannot be used #5644
Comments
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/gpio84/value cat /sys/class/gpio/gpio80/value |
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 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 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: 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/ ls -ls /sys/class/gpio/gpiochip412 ls -ls /sys/class/gpio/gpiochip427 ls -ls /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 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. |
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 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):
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
|
By contrast here are results in Raspberry P1 1B+ using gpiod:
|
Then one can make code dynamic to pin name and not GPIO line number nor GPIO chip: sbc@PiUPS:~ $ gpioget $(gpiofind "SDA0") |
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:
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
GPIOChip=0
UPSOnlineStatePin=27
UPSPiStatePin=18
UPSPowerStatePin=17
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.
The text was updated successfully, but these errors were encountered: