5.15.x kernel Rock Pi 4B+ GPIO regression

[dgatwood]

This feels really awkward, since I already asked about this problem in another part of the forum, but the bug reporting system says that bugs should be reported by posting in this section of the forum.  Feel free to merge the other thread into this one if you want.  (Link at bottom.)

 

Linux kernel 5.15.x appears to have a serious regression that prevents GPIO from working correctly on the Rock Pi 4B+ (board version 1.73).

 

Summary:

• All GPIO4A pins are nonfunctional:
  • Pin 12 stuck off
  • Pin 35 stuck off
  • Pin 36 stuck off
  • Pin 38 stuck off
  • Pin 40 stuck off
• GPIO1B is nonfunctional.
  • Pin 19 stuck off
  • Pin 23 are stuck off.
  • Pin 24 is stuck on
• GPIO4C is partially working.
  • Pin 8 is stuck on (serial overlay?)
  • Pin 10 is stuck off (serial overlay?)
  • Other 4C pins work as expected.

 

All other pins work.  No overlays are explicitly enabled, and the documentation says that all overlays are supposed to default to off.

 

What I've tried:

 

• Using my own code (first discovered) linked against mraa C library.
• Using mraa-gpio.
• Using echo commands in /sys/class/gpio/.
• Switching kernels with arbian-configure:
  • 4.4.213-rockchip64 - works as expected
  • 5.10.16-rockchip64 - works as expected
  • 5.10.63-rockchip64 - works as expected
  • 5.15.25-rockchip64 - GPIO malfunction as described above.
  • 5.15.63-rockchip64 - GPIO malfunction as described above.
  • 5.19.5-rockchip64 - GPIO malfunction as described above.

 

So it looks like GPIO broke rather badly in the 5.15 branch and after, but is working in the 5.10 branch.  Either that or some overlays are getting turned on by default somehow (but Armbian doesn't seem to have a syntax to turn them off as far as I can tell, so the net effect is the same).

 

In a related bug, the exact same set of problem pins work only when running as root in 5.10.x and 4.4.x, whereas all other GPIO pins work correctly as a non-root user when the sysfs nodes have the correct ownership and permissions applied.  This suggests that there is some chunk of code that reconfigures the SoC to set those pins to be GPIO output pins that either A. is incorrectly being guarded by a root UID check in 5.10.xx or B. is on some other /dev or /sys node that I failed to chown/chmod, and is either missing entirely or not properly exposed in devfs or sysfs in the 5.15.x kernel.  Not sure if that will help narrow the search for the bug, but it seemed relevant.  🙂

 

And before you read the log linked below and ask me about it, yes, I know that the image I installed was apparently for the Rock Pi 4c.  I changed the overlay already and swapped out the two 4c-specific packages with their 4b equivalents, and it made no difference.  And then, just to make sure it wasn't something that I missed, I loaded the 4b image onto a flash card, and it failed in the same way with the 5.15.x kernels.

 

Armbianmonitor log:

https://www.gatwood.net/bugs/armbian_info.txt

 

 

 

For more info, see the original discussion thread:

 

 

Edited September 16, 2022 by dgatwood
Added bit about the non-root pin problems in 5.10 and earlier

[dgatwood]

Correction: I am unable to reproduce the problem with being unable to change the pin state of certain pins as a non-root user when using the mraa-gpio tool, at least in 5.10.63, so I'm not sure what was going on with that, but it is unrelated to the 5.15.x regression.  I was trying to debug too many problems at once, I guess.