I started a project on Raspberry Pi 4B, then discovered that they were unobtainable and am trying to replace it with a Rock Pi 4 SE.
I want to use SPI to light up some WS2812B addressable LED strips. I’m currently using the latest Armbian but am open to using another distro if I can simplify the process.
I’ve enabled SPI using armbian-config and editing /boot/armbianEnv.txt to add an SPI bus parameter to enable /dev/spi1.0:
overlays=spi-spidev
param_spidev_spi_bus=1
I can verify that /dev/spidev1.0 exists:
$ ls /dev/spi*
/dev/spidev1.0
I’m connecting the LED strip in the same way I did on the Raspberry Pi. I’m using a standalone 5V power supply, ground connected to the LED strip and also to a ground pin on my Rock Pi, power connected to the +5V on the LED strip, D0 or whatever you call it connected to pin 19 (MOSI).
Everything seems okay. My app is a dotnet 6 app using Iot.Device.Ws28xx. I can verify that I’m using the correct SPI bus; if I use the wrong bus it throws an exception:
System.IO.IOException: Error 2. Can not open SPI device file '/dev/spidev2.0'
But, on the Rock Pi 4 SE, it just does not work. I have tried connecting my LED strip to pin 21 in case things were confused. I’ve tried connecting it to pin 29 and 31 in case something got lost in translation and I was really controlling what is labeled SPI2. I’ve tried enabling SPI 2 instead and using SPI2 with each of the four pins. Nothing works.
I feel like I must be missing something basic but I’ve been through every scrap of documentation and can’t think of anything else to try.
Like Igor said (head of armbian) - Armbian is largely underfinanced so many things are not tested,not verified and support depends only on money (You can hire someone at armbian to try to fix issues). For now most users won’t even report any problems because that is all they can hear. Either use it as it is or switch to something else that may work for Your features. While I like few ideas about armbian and it’s build system it’s mostly unstable and none of images so far could run for longer time producing sooner or later kernel panic on my setup.
Maybe try something else, radxa images are now in a process of change/rebuild, but probably higher chance that gpio is working there.
Armbian has pretty advanced testings and advance development. Its not a problem to find problems or give users opportunity to report them. Core of the problem is resolving bugs or its prioritising. It is expensive and 1-2 full time staff would be needed just for managing them. But if working in McDonalds is paid a lot better, people rather work there. For volunteers this is just some stupid boring non glorious work to avoid at all cost … Average bug resolving rate for things we record on our own is around 450 days. To understand capacity. Budget is plain zero. Nothing. Nada.
Another problems are open source parasites. Those which are receiving all fixes and never put anything on the common table. When time is paid, I don’t care also when credits are removed form the code.
Business model of selling cheap single board computers is based on exploiting developers community, from two strong parties - users and vendors. Those are just facts.
Rpi had a lot of “backers”, so support is good. Here both, paid and free, is in very low number and most of users are spoiled with Rpi level of support, demanding the same. And from us !? With zero R&D budget and very small community which helps.
Support is usually the only way to finance FOSS development. Donations are good enough for projects that are not dealing with real problems - most of amateur Linux projects. Others you have to support & finance. If you don’t, frustration will just keep growing poking into your face. We all loose. You in having good software software, developers having fun making and maintaining it.
I know many open source developers that are extremely frustrated because of this retarded bug fixing demand users attitude. You can’t demand from amateurs to focus on problem you have for weeks. Its rude even to ask politely.
And complete absence of appreciation. There are very very little heroes that are willing to sacrifice weeks of their private time to fix one bug. While there is a stream of bugs …
I am afraid, you can’t as there is not free capacity. It is extremely difficult to find people that would like to deal with hard work and listen to insults even they see this as a mission or for nice money.
Asking for payment is a polite version of “we have no resources, there is nothing we can do, it will take years to fix this …”
We are fixing problems in software you are trying to steal support time from us with a rate of lets say 30 - 50 hours per day. Just try to cover that? Current coverage is 0.5%
There is one great opportunity to participate outside filing bugs and making demands.
Many people in this business would wish that just applying money would solve everything.
If there is HW related bug -> https://bugzilla.kernel.org/ Why would we need to fix bugs for entire Linux community? Do entire Linux community helps us? No. Most don’t even know we exits.
I feel like I have touched a sensitive area and need to back up slowly while smiling and nodding!
Thanks for the perspective. I understand that Armbian is available on a very broad range of hardware and can’t spend a great deal of time ironing out hardware support for each device.
GoGerriko: I think you are right that spi2 and spi3 are mixed up.
I see what you mean about vendor-based images vs. mainline images. Thanks! This was the hint that I needed to hunt around radxa-build on github to find the current release page for my board. The wiki for Rock 4 SE has only a single link to a two-year-old Debian desktop image, which left me feeling like Armbian might be the only up-to-date option. I am surprised that Radxa would focus their efforts on vendor images as opposed to improving hardware support in a distro like Armbian, and I am still confused about which images are officially supported and which are prerelease.
I guess it doesn’t matter. I’ll just try some options to see if I can find something that works. It seems to me like the first vendor to really nail software support the way Raspberry Pi has will be positioned to slide right into the vacancy created by Raspberry Pi’s seemingly endless supply issues.
In case anyone else follows my path, here’s where I’m at:
[rock-4se_ubuntu_focal_cli_b33.img.xz] does not boot on my hardware (this is an official release!)
[rock-4se_ubuntu_jammy_cli_b33.img.xz] does not boot on my hardware. This is a prerelease build.
[rock-4se_debian_bullseye_cli_b33.img.xz] This one boots! Enabled spi1 with rsetup. Just like Armbian, my app thinks it’s writing data to SPI but none of the pins appear to be doing anything.
Has anyone got SPI working on the Rock 4 SE with any Linux distro?
It is significantly cheaper to maintain private frozen kernel, features support are close to complete and since kernel is not getting any updates, features won’t stop working.
Very little people actually care & understand what is the difference between this and mainline Linux. You want that things just works and with this HW interface this is achieved only this way. Mainline direction is developing this support from scratch. Development is fun part, while maintaining, securing that features actually works after upgrades and features specific to some revision of some hardware … that is completely different game. If you don’t support people that do that, they will just stop and problems you have, you need to fix on your own. Armbian gives you powerful and well maintained build framework, where you can start from … be happy that such independent ecosystem exists.
Other Linux distros will be selling you the same or worse under different name.
@igorp - I don’t want to go over this yet again, but clearly You negate yourself over and over again. Defending Armbian as so much sophisticated and tested and then saying that with it’s approach some features just stop working. Talking about “parasites” and “common table”. Frustration and mcDonald job. Users demanding something and money. Let’s just stop at this point because it’s way to nowhere and I still think You will never build up good community around project with this approach. Same thing over and over again when someone asked about some basic functionality.
Yep, You used two keywords to activate Igor One is name of project and second one probably anything about bug/issue/problem. Just don’t worry
Radxa is not that big company with so many resources, on the other hand they make much interesting products worth to see.
Radxa is now at process of rebuilding all images and release process. They announced new build system with information that for now ubuntu has some problems and don’t work. I think they should just delete corrupted images from releases or even put information there. Hopefully they will improve soner or later.
I have mixed feeling about rsetup for now, when I tested that I wasn’t even not sure if overlays are dedicated to my particular board. Also recently kernel was updated from 4.14 to 5.15 (by rockchip, then by radxa), maybe worth to check out older image with previous kernel.
I don’t have SE version but I as far as I remember I was checking SPI LCD year ago with 4B+.
Few things are tweaked and turned via device tree and overlays. I think here is the problem - as mentioned I think that this list of overlays is wrong and may be for something on rk3588. That is why it dont worked.
Possibly You can just copy those files from older release and use it on new one. Also its possible to decompile, view, change, compile those on new release. If you really need newer kernel then probably you can compile it on old release too.
I think that they wanted to split it to few repositories and automate build process as much as possible producing bit too much on start with not easy way to mark now something as broken. It’s fresh thing and probably will be better than bunch of manually created images uploaded to some clouds and referenced statically on wiki.
For now I think its still beta quality, but they need some tests and help now to improve.
Thankfully You managed to get it working on some image so now its bit easier to compare what has changed. Kernel alone is quite easy to recompile and replace. For rsetup - I think that it needs some time.
As I have a rock 4se on the way (3399t) , and as usual read up on informations too late:
In the download section, it came to my attention, that images for this 4se board , is not specific for this underclocked version of the 3399 soc ?
Maybe this is not a problem with android. But Libreelec , I can understand, that this low cpu speed , can be an issue if trying to install ex. a 4a release.
As of now , it seems (still) that the only OS for the 4se , build especially for the 3399T is Ubuntu.
So still no news for this board , or am I missing something?
And/or : is it safe/a fluid experience to install ex. android version, which in the 4se download section, is an image for the rock 4b with a stronger cpu
Thanks
EDIT: All images for rock4 (non SE) seems to work without any issues on the Rock 4SE, although the SOC clockspeed is lower.
I don´t have any overheating or unnecessary load
I had similar experience on the 4C+, but the overlays specific to 4C+ were needed, which I got from one of the overlay repos and from an older version of radxa release.
One is name of project and second one probably anything about bug/issue/problem. Just don’t worry 