GPIO on Rock Pi 4B+

[dgatwood]

Cross-posting from the Radxa community, because I've not had much luck getting replies over there, and hoping this forum is more active.

 

I’m in the process of porting a VISCA/NDI camera controller from Raspberry Pi to run on Rock Pi (4B+ version 1.73), and I’m running into some serious GPIO hardware failures that I don’t quite know how to deal with.

As a starting point, I took a pre-built collection of LEDs and disconnected them from a working Raspberry Pi setup and connected them to the Rock Pi. They all worked fine when driving them from the Raspberry Pi, so I’m reasonably certain that the problems are specific to the hardware or drivers on the Rock Pi side, and are not bad LEDs or other wiring mistakes.

 

And I’m seeing the misbehavior from the mraa command-line tool, which likely rules out anything in my code.

 

I’ve also tried switching to a different power supply, with no effect.

 

Here’s what I’m seeing when I do “sudo mraa-gpio set XX 1” for any given pin XX:

 

• Pin 32 (GPIO3_C0) works exactly as expected, and is the only fully functional pin.
• Pins 29, 31, 33, and 37 light up, but every 1.3 seconds or so, the brightness dips twice in short succession, in a rhythmic fashion. Apparently, these pins are 3V by default, and the working pin is 3.3V by default, so I’m thinking that the 3V regulator on this board is unstable for some reason, or that something is pulling the entire bus low, I’d like to set all the pins to use 3.3V, but I can’t find any documentation about how to do that (if it is even possible in software).
• Pins 35, 36, 38, and 40 do not work at all. I’m guessing this is some secondary function interfering with it, but no overlays are turned on, and I can’t find any documentation that provides any other hints as to what might be wrong. I did notice that fdtfile was wrong (pointing at the 4c), and changed that, but it made no difference.

 

What’s even more bizarre is that pin 29 is turned on by default right after booting at about a 50% booting cycle (the Raspberry Pi does the same thing), and the LED doesn’t start the periodic flashing until I use mraa-gpio to change its state.

 

Any ideas? Another dud board? Kernel bug? Hardware bug?

 

Configuration:
Rock Pi 4B+
Armbian Jammy (Desktop)
MRAA library from top-of-tree on GitHub (because no Jammy binary builds exist for MRAA, apparently)
No overlays enabled
Tested with official Rock Pi power supply and Apple 87W USB-C supply

[dgatwood]

Just to clarify, those nine pins are the only pins that I tested, because those are the pins that the existing wiring harness uses.

[Werner]

Moved since not a tutorial or similar but a question.

[dgatwood]

Ah, thanks.  I assumed that section was for advanced questions, including GPIO and tutorials, rather than tutorials about GPIO.  🙂  My bad.

 

So here's what I've figured out so far:

• Those pulses on every GPIO output are exactly in sync with the heartbeat on the blue status LED.
  • The blue status LED causes a 0.02V drop across my other LEDs whenever it lights up (.01V when measured at high impedance without a load).
  • Disabling the heartbeat fixes the flashes.
• About half of the GPIO pins are nonfunctional:
  • All GPIO4A pins:
    • 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 (probably a serial overlay turned on)
  • Pin 10 is stuck off (probably a serial overlay turned on)
  • All other pins work
• All other GPIO pins work.

It acts like multiple overlays are turned on, including one of the serial ports, but there are no overlays enabled in armbianEnv.txt.

 

So I finally tried switching to kernel 4.4.213-rockchip64.  Now, those pins work, but only as root.  The other pins work as expected even as a non-root user.  I'm not getting any errors from the mraa libraries as a non-root user, but the above pins fail to work correctly.

 

Unfortunately, running the code in question as root is not an option, because it involves third-party binary libraries, and thus must run as an untrusted user for obvious reasons, so I'm going to have to figure out a way to deal with that.

 

So I'm still partially stuck, but at least I know that a large part of the problem is the 5.x kernel.

 

[dgatwood]

It works correctly on every kernel version from 5.10.x down, and fails on the oldest available 5.15 kernel (5.15.25) and on the latest 5.19 kernel (5.19.5).  I'll file a bug.

[dgatwood]

Adding further to the strangeness, the board is being incorrectly identified as a 4C in the armbianmonitor output:

 

737 ### armbian-release:

738

739 # PLEASE DO NOT EDIT THIS FILE

740 BOARD=rockpi-4c

741 BOARD_NAME="Rockpi 4C"

742 BOARDFAMILY=rockchip64

 

Even though the armbianEnv.txt config file is right:

 

    fdtfile=rockchip/rk3399-rock-pi-4b.dtb
 

So if 5.10 didn't support the 4b and 5.15 does, this could be the problem.

 

After digging through that log, I've now removed the following packages:

• armbian-bsp-cli-rockpi-4c
• linux-u-boot-rockpi-4c-current

and installed the following replacements:

• armbian-bsp-cli-rockpi-4b
• linux-u-boot-rockpi-4b-current

then ran armbian-config to switch to the 5.15.x kernel again.

 

Same problem.  And still misidentified in every armbian-release section.

 

 

Oh.  I see what's going on.  It's just dumping the contents of /etc/armbian-release, and apparently the reason it misidentified the board before was because I downloaded the wrong image.  On this page:

 

    https://www.armbian.com/rockpi4/ 

 

it says "Images below are for model C. For A (without wireless) can be downloaded here and for B here."  Unfortunately, that text appears below the actual downloads, and below the bottom of the screen, so nobody downloading the images will ever see it.  *sigh*

 

However, none of this should affect the kernel in any way as long as it is loading the right overlay, presumably, unless I'm badly misunderstanding something about the way embedded ARM kernels work.  (I haven't dealt with them much since the 2.2/2.3/2.4 kernel days, so I'm a little behind in my knowledge. )  So I *think* the only differences are the contents of the "armbian-image-release" file, the two board-specific packages, and the fdtfile line.  Right?

 

I'm downloading the correct image now, and will write it to a flash card and see if it makes a difference.  I really don't want to spend another three or four days wiping, reinstalling, and reconfiguring things unless there's a chance in you-know-where that it will help.

 

armbianmonitor -U output:

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

 

[dgatwood]

Verified that the 4B image behaves the same way (broken GPIO).