Jump to content

dgatwood

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Another thing to try is jumpering pins 23 and 25 to disable the SPI flash, in case it contains a booter that conflicts with what the OS needs.
  2. One reason that didn't work may be because it's a mix of the Armbian syntax and the Debian syntax. It should be: overlays=[name of overlay] But I see you also used a different maximum speed. Assuming that's not a typo, you can create a new overlay like this: 1. Save the following (assuming I didn't make any mistakes) as rockchip-pcie-gen2-updated.d2s (wherever): /dts-v1/; /plugin/; / { model = "ROCK PI 4B"; compatible = "rockchip,rockpi", "rockchip,rk3399"; fragment@0 { target = <&pcie0>; __overlay__ { max-link-speed = <0x03>; }; }; }; 2. Compile it: dtc -O dtb -o rockchip-pcie-gen2-updated.dtbo rockchip-pcie-gen2-updated.d2s 3. sudo mv rockchip-pcie-gen2-updated.dtbo /boot/dtb/rockchip/overlay 4. Edit /boot/armbianEnv.txt and add overlays=pcie-gen2-updated or if you already have a line, add a space and add "pcie-gen2-updated". Note that you drop both the extension and the rockchip- prefix in the overlays field. If that doesn't work, try changing &pcie0 to &pcie.
  3. 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.
  4. Sounds like the boot device is wrong. It's trying to boot from internal flash that doesn't exist. I would flash an SD card and boot from that (I think SD cards take precedence over NVME), then use that to fix whatever is broken. Not sure if editing the root device in /boot/armbianEnv.txt is adequate or not, but you should change it to a UUID so that it is unambiguous and won't break if device order/count changes or whatever, e.g. rootdev=UUID=ae350ad9-22f5-46a1-9508-98af2fe9ba52
  5. 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:
  6. Verified that the 4B image behaves the same way (broken GPIO).
  7. 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
  8. 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.
  9. 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.
  10. Just to clarify, those nine pins are the only pins that I tested, because those are the pins that the existing wiring harness uses.
  11. 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines