I also have the same problem, it used to work fine with an older version of armbian and the old 4.4 Kernel, but after an upgrade it just stopped working. The following should serve as a test when connection MOSI and MISO: ~# dd if=/dev/urandom bs=1 count=16 status=none | spi-pipe -d /dev/spidev1.0 -s 1000000 -b 16 | hexdump -C Querying my MCP3008 it just returns all zeros: ~# printf '\x01\x80\x00' | spi-pipe -d /dev/spidev1.0 -s 100000 -b 3 | hexdump -C 00000000 00 00 00 |...| 00000003 I'm using the following DT: /dts-v1/; /plugin/; /{ metadata { title = "Enable spidev on SPI1"; compatible = "unknown"; category = "misc"; exclusive = "GPOI3_B2", "GPOI3_B3", "GPOI3_B4", "GPOI3_B5"; description = "Enable spidev on SPI1 on pin 39, 40, 41 & 42."; }; }; &spi1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi1_clk &spi1_csn0 &spi1_miso &spi1_mosi>; #address-cells = <1>; #size-cells = <0>; spidev@0 { compatible = "rockchip,spidev", "armbian,spi-dev"; reg = <0>; spi-max-frequency = <50000000>; }; }; The SPI is showing up, but it's just always producing zeros, it seems there's just something wrong with a newer SPI driver or something, maybe a new kernel upstream fix or kernel patch is needed here. I sadly don't have a backup of the old image to test with, but it the same rust software I wrote that worked before, doesn't work anymore now and it can't even talk to itself anymore. I don't have an oscilloscope to see exactly whats going on, but something funky is happening with the clock signal indeed: ~# cat /sys/kernel/debug/clk/clk_spi1/clk_rate 108333334 Max clock should be 50M as per the DTS file, but it seems the driver just ignores this. Event though spi-config shows something else (when reconfiguring it): /dev/spidev1.0: mode=0, lsb=0, bits=8, speed=100000, spiready=0 I also don't find any way to build an old kernel 4.4 image anymore (the legacy branch doesn't exist anymore), so I can't do that either and the edge-based Kernel 6.18.0-rc6-edge-rockchip64 also don't bring any improvements it seems.

Have you tried other wine/proton versions?

Realistically I can't promise that. But I think with very small patches this board can work (it already does, minus the ethernet and armbian-install). I will try to solve the problems in this board and then post my solution here (as a single post, not as a series of posts). I don't think it needs to be added to the list of supported boards as long as this thread is indexed by search engines and someone else with the same board can use these forums to successfully install armbian on orangepi cm5.

Probably the latter. https://docs.armbian.com/User-Guide_Board-Support-Rules/ has more information. We already have a lot of boards in Armbian. Probably too many from a maintenance POV. Do you simply want to do the work of bringing up your board in Armbian or do you want to become the maintainer of this board going forward? That's an artefact that @Igor may be able to fix. The page should not really exist at this point.

I decided to klipperize an old 3d printer and found some of my orange pi boards dead, so i ended up selecting my XU4 for the task. Fast forward 24 hours and i'm fighting MCU timeouts. Klipper doesn't know what happened just that the mcu stopped responding. And their knowledge base article is basically "gosh it could be anything". One seat of the pants observation i made was that the XU4 idles along at 600mhz with a load average of about 0.1 and it seemed like the load average increased maybe before the mcu stopped responding. The MCU in question is an SKR Pico, aka rp2040 with a usb connection. The mcu is not receiving power from the xu4 (there's a jumper) - I've tried both usb3 and usb2 ports on the XU4 with no difference. I recall that many years ago i resolved a similar issue with an H2+ based board and Octoprint by switching the cpufreq governor to "performance" which of course just pegs it at the top speed. But on that board, armbian-config lets me select what that maximum speed is, so as to avoid overheating. My XU4 is equipped with the flat little fan. I do have some large heatsinks and thermal adhesive. I'm a little worried that it might run too hot if it's at 1.4ghz all the time. sysfs tells me there are a ton of scaling frequencies available, but it appears that i can't just, select one. Any hints?