Well, this turned into a very long day. The 4*A76 and 4*A55 show up as 8 cores. I guess the faster cores will just finish and get more work faster.

It should be an interesting SBC. Ethernet, Wifi, sound, the GPU, VPU and NPU all report for duty. And so do the HDMI outs and the interesting HDMI in. Whether all work as expected is for testing and fixing another day.

So this is a bit of a rabbit hole except there be dragons in that hat! Since I’m just waiting for some rebuild I’ll do a little update:

The Radxa 5 series have two workable approaches, but neither is perfect. They are imperfect in different ways though:

1. The official Radxa setup forked off at about linux kernel 6.1, and there are many proprietary blobs and drivers to make things like the NPU and VPU work. Reportedly it does so just fine. I made an image with that, but then hit the combination of wanting a browser kiosk solution with Mali GPU acceleration. Several possible ways were tried but in the end the conclusion was that I couldn’t make the Mali GPU driver work with 6.1 kernel needed for the other stuff. For the 5T I also had to backport the Wifi driver. (Reference if anyone else have a go at this version).

2. The other path, which initially at least was much smoother, was going with the mainline linux kernel and the amazing work of Collabora and all their patches and improvements for the RK3588. Getting a kiosk up and running with Mali GPU acceleration was just fine. Thus the setup I’m working on now is based on their stable 6.18 linux kernel for the RK3588. No proprietary out of reach secret blobs, but on the other hand not (yet) full NPU and VPU functionality.

   For the NPU though Tomeu Vizoso have obviously put serious work into making an open source alternative. Drivers and libraries like Rocket, Mesa and Teflon make the NPU available without the Radxa proprietary blobs. The NPU has 3 cores though, and currently the above will only use one. Thus I’ve put up a round robin worker pool where each worker gets their own video frame. 3 workers are busy at the NPU at any time while a 4th worker is busy loading up the data to use. That seems to work pretty well. XLA does not support the NPU yet though, so a nice Elixir EXLA/ Axon/ NX solution seemed out of reach. Thus it is now built around a Rust NIF.

   The VPU functionality on this the open source alternative is currently limited to full HD decoding in various codecs and just jpg encoding. For higher resolutions it seems some OpenCL work might be needed.

   The headphone sound has had me stumped for hours and demoralized. The chip is old and used on many other SBCs for years so one would think it would be a well explored and documented how to make it work. I finally found the 37 page user guide to that chip, and most pages seems to be registers to combine and set just right. If I happen to get sound I’ll play the lottery the same day for sure!

   The 3588 also have two ISPs handling up to 48 megapixels. That was a welcome surprise, although I still have no idea of how to actually access or use them. Later is probably the right time for that.

Yes, it slowly dawned on me after posting that the M0 core is actually the same as used on the RP2040. If a core is not capable it makes sense that it is just ignored. It seems it was added more as a coprocessor for GPIO pins and so on. If I can find a half justified use case I’ll play a bit with that and see how that goes.

But for more capable different core processors I assume the logic then is that Nerves will use all cores capable enough? And for better or worse match the workload with their relative capabilities? That would be quite impressive out of the box!