GPIO | Latest kernel deprecates sysfs API #5385
Comments
MichaIng
added
Armbian
Kernel related 🧬
Investigating 🤔
Workaround available 🆗
|
Many thanks for your report. More issues with Armbian Linux 5.15 😢. But the NanoHatOLED application may generally require an update for Linux 5.15 and above, hence probably not a bug in the Armbian kernel. Just to assure we're talking about the very same application: It's what you installed from here, right? Can you provide logs of the failing application? You can downgrade the kernel, but note that this way you reintroduce the Dirty Pipe vulnerability: apt install --reinstall --allow-downgrades 'linux-image-current-sunxi64=21.08.1' 'linux-dtb-current-sunxi64=21.08.1'
apt-mark hold linux-image-current-sunxi64 linux-dtb-current-sunxi64 |
|
Hi @MichaIng, Yes, I mean https://github.com/friendlyarm/NanoHatOLED I will re-think about downgrading. Thanks, Maarten |
|
Cross linking our issue at FriendlyELEC: friendlyarm/NanoHatOLED#13 It was just an idea that it may require an update, but shouldn't hurt to have FriendlyELEC informed as well as their README explicitly states that it works with Armbian. And they will know better how to debug as well. Btw, did you already update the application to the latest version by rerunning the install instructions? |
|
Yes I did the update to no avail! |
|
Good. friendlyarm/NanoHatOLED#7 seems to have been solved with a BakeBit submodule update. Latest NanoHatOLED however uses latest BakeBit already, both are developed by FriendlyELEC anyway. Running |
|
Hi MichaIng,
|
|
Is a workaround possible? |
|
Okay, GPIO device tunables seem to be missing completely, as well as board specific /proc/cpuinfo. I'm not sure what NanoHatOLED requires exactly, I guess the GPIO tunables are the critical part. I checked currently available device tree overlays for enabling GPIO in general, but there is only As a workaround you can downgrade the kernel as stated above. Best is to test with a fresh Armbian Bullseye image: https://www.armbian.com/nanopi-neo-2/ |
|
Hi MichaIng, How do install dietpi when installing fresh Armbian Bullseye image: https://www.armbian.com/nanopi-neo-2/ ? It will take a lot of working re-installing all applications and customizations. So at this moment not really an option for me. Maybe in future when I have more time. |
|
The idea is indeed to just flash Armbian and verify that NanoHatOLED fails the same way, so that it can be reported to Armbian as a bug. Once you install DietPi, Armbian will say they do not support 3rd party users, reasonably, so that would break the purpose 😉. I didn't mean this as replacement for your running system, but just as temporary test to allow Armbian bug report. I.e. use a separate SD card or USB drive for this and keep the DietPi system untouched (respectively downgrade the kernel on it to get the OLED back up). |
|
Good point, I'll check it this week and let you know. Thanks a lot for your great help and support! |
|
Have reverted to previous kernel |
|
So indeed |
|
I think so. Results from fresh Armbian installation (https://www.armbian.com/nanopi-neo-2/) are the same: |
|
Okay, that is one issue, the other is the missing GPIO sysfs entries. Can you show: ls -l /sys/class/gpio |
|
output of But is that not due to NanoHatOLED not running ? |
|
Nope, NanoHatOLED uses the GPIO devices, it does not provide them. It fails because the GPIO devices are missing. |
MichaIng
added
External bug 🐞
|
Thanks. I'm testing on NanoPi NEO3 now. Different SoC, but need to replicate #5378 anyway. |
|
On NEO3, Lol after kernel upgrade, it doesn't boot anymore, or network does not come up anymore. Nasty with a device without HDMI, and I'm not keen to remove the tight case yet for attaching a serial console. ... next attempt, now |
|
Yes, problematic when only serial console is left over to connect. Good luck! |
|
On NEO3, the GPIO interface remains. There was a much more critical issue since it became unbootable with the new kernel. We need to switch to a NanoPi R2 device tree to keep it up: 86726aa But now it boots and GPIO interface/devices are there. So it seems to be an issue specific to the NEO2 or Allwinner 64-bit kernel. |
|
About your report at the Armbian forum:
I do not understand the rules in which actual support is granted by Armbian. The NEO2 is an officially supported board, the kernel upgrade breaks the GPIO interface completely, and they just move it to P2P (users help users), as if you just had a personal issue with your individual setup 🤔. Igor itself is listed as maintainer for this board, now I'm not sure whether he even reads posts in P2P forum. Let's see. |
|
Hi @MichaIng, Thanks a lot again for your support. We'll see, will stick to previous firmware for the time being. |
MichaIng
changed the title
|
Hi @MichaIng, Since I have marked the latest kernel update as hold back with APT, the update notification for these packages remains also. Is there a way to suppress the notification for these two packages only? |
|
This should make APT not considering those packages at all: cat << '_EOF_' > /etc/apt/preferences.d/ignore-kernel-upgrades
Package: linux-image-current-sunxi64 linux-dtb-current-sunxi64
Pin: *
Pin-Priority: -1
_EOF_ |
|
See here, it seems to be a deprecation in upstream Linux itself: https://forum.armbian.com/topic/20115-gpio-depreciation-sysfs-on-o-pi-no-sysclassgpio-anymore/ This is now in "obsolete": https://www.kernel.org/doc/Documentation/ABI/obsolete/sysfs-gpio Looks like a lot of tools/software developers haven't recognised this, neither did I. While the Armbian maintainer is looking into a way to restore it, as it is officially deprecated, it won't last forever. So then the ball is again at FriendlyELEC to move to recent GPIO library, i.e. libgpiod. The package text also states that it makes features available, not present in the obsolete sysfs API. |
MichaIng
changed the title
MichaIng
changed the title
|
Found a kernel config to restore it, posted in both topics. Hopefully the maintainers can apply this quickly and make a new kernel release 🙂. |
|
Hi MichaIng, Thanks for your help on this issue on the Armbian forum! If I understood well, the issue is being addressed. Do don't know how it works but when is the 'repaired' kernel available as package through APT update/upgrade? Thanks, |
|
I don't know when Armbian will release the new kernel, but it shouldn't take so long. Keep a view at the login banner for available APT upgrades, respectively run |
|
Yesterday evening Armbian 22.05 was released which solves the problem. |
MichaIng
added
Solution available 🥂
|
That is great news, many thanks for reporting 🙂. I'll mark this as closed then. |
|
Hi, I bought a NanoPi Neo (H3). I am new to Armbian, but not new to Debian. The NanoHat OLED works fine with UbuntuCore 16.04 and kernel 4.14. Now I installed a new microSD card with latest Armbian Bullseye. But the NanoHat doesn't work. Armbian is up-to-date: I followed the installation instructions: here for Armbian Stretch and after that for Armbian Buster. In both cases the NanoPi rebooted automatically and I didn't see any issues while the script was executed. The OLED stays black. I don't know, if the following information is relevant: What am I missing? Thanks and regards Hoppel |
|
The more often I press the knobs, the more events I see here: So the buttons work, but the display stays black. This is what I see, when I execute the script: Logfile attached. Click to expand!What can I do to analyse the issue? Any idea? Thanks Hoppel |
|
Found a solution for Armbian 22.05.04 Bullseye (5.15.48) and described it here: https://forum.armbian.com/topic/22276-nanopi-neo-h3-nanohat-oled-doesnt-work/#comment-143564 Regards Hoppel |
|
Awesome, many thanks for sharing! |
NanoPi NEO2 (DietPi bullseye)
After latest kernel update my NanoHatOLED application does not start anymore or it starts but ends immediately,
Is it possible to revert to previous kernel version? How?
The text was updated successfully, but these errors were encountered: