Active threads

Hello, I'm from China. I bought an H96 Max M9S (8GB+128GB) for 500 RMB. After reading your discussions, I've learned how to use RKDevTool to flash the Android system via USB. However, I've been struggling for several days and still cannot boot the Armbian system. Could you please tell me how to boot Armbian? Is it possible to flash the Armbian system directly to the eMMC of my M9S using RKDevTool? I really need your help. Thank you very much!

I tested v25.11.1 https://www.armbian.com/orangepi-5/ released yesterday - vendor kernel, Gnome desktop, acceleration works, 4k video playing with Chromium, audio works ... Since I don't have model + right on hand, i didn't test it. But its very similar board and I assume it works. It should even boot with image for normal Opi 5 but all peripherals won't be working correctly.

I purchased the device after reading your thread and am currently porting it to my hardware with Copilot (Claude Sonnet 4.5). You can refer to my work results in the repository below. So far, the following parts have been confirmed to work: HDMI (no need to reconnect after Linux kernel boot) Ethernet Built-in eMMC Currently working on: Wi-Fi / Bluetooth (in my case, the model uses AIC8800D80) Not yet verified: GPU Install to eMMC As suggested in your thread, I based my work on the Hinlink HT2 and Radxa Rock 2F, using the DTB extracted from my device’s firmware and processing it with Copilot. I’d appreciate it if you could take a look if you’re interested. IMG_1597.HEIC https://github.com/wwwhana/armbian-build

> if that minimal package were part of the stock system, so the armbian-install doesn't break did your system break following the f2fs-tools install or were you able to format with f2fs and install your system in armbian-config?

you can try: sudo systemctl status rpcbind if there are any problems or it's not enabled try: sudo systemctl enable rpcbind sudo systemctl start rpcbind

Tried to get it running on the Rock PI S, which has the same chip, but it somehow doesn't seem to work... I think it has different conflicts maybe? It's kinda hard to debug. Originally I used the following (on 24.*): /dts-v1/; /plugin/; / { compatible = "rockchip,rk3308"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; spidev@0 { compatible = "rockchip,spidev"; status = "okay"; reg = <0>; spi-max-frequency = <10000000>; }; }; }; }; But it stopped working on upgrade to 25.11. I was able to get it to load again until I adjusted the compatible field to "armbian,spi-dev". But the the connected chip just wouldn't answer. I now tried rk3308-spi1-spidev.dts from this thread, with the codec modification and then even tried to fix the correct conflicts for the Rock PI S' different pinout: /dts-v1/; /plugin/; /{ metadata { title = "Enable spidev on SPI1"; compatible = "radxa,rockpis", "radxa,rock-s0"; category = "misc"; exclusive = "GPIO2_B1", "GPIO2_A4", "GPIO2_A5", "GPIO2_A7"; description = "Enable spidev on SPI1."; }; fragment@0 { target = <&spi1>; __overlay__ { 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 = <10000000>; }; }; }; fragment@1 { target = <&i2c3>; __overlay__ { status = "disabled"; }; }; fragment@2 { target = <&uart3>; __overlay__ { status = "disabled"; }; }; }; But it still doesn't communicate. It's there, but not receiving any data from my chip like it did in the past. I can't find anything in dmesg, so I'm not sure how one can find out what's wrong with it.

We don't have resources to deal with this question, but I think, in case of this hardware, there is just firmware package (armbian-firmware / linux-firmware) that fits into this. Perhaps some other util. There must be some scripts to scan Debian packages and tell? From my head, I remember iozon3 package (might not be by default on minimal) that is non-free https://packages.debian.org/bookworm/iozone3

Great reply , I'll knock up a connection! much easier than anything else. I work in modern/future vehicles so the spikes and dips are not an issue for me as none of them have engines.

@Hqnicolas thanks for your presentation. I found I made an error : mkdir -p ./build/userpatches/kernel/archive/rockchip64-6.12 should be : mkdir -p ./userpatches/kernel/archive/rockchip64-6.12 as the current directory is build at that point. For wsl installation @NicoD made a great video here :

rk3326 and rk3328 are not the same thing, neither is px30. Definitely no chances to run this on those SoCs; I don't know if there are images for boards using px30/rk3326 in armbian.

For SBCs without own audio I use networked pulseaudio. I never got it to work in newly installed Jammy and Bookworm, also not in Bookworm upgraded in-place to Trixie. It worked in Buster, BuIlseye and allways worked in Opensuse Tumbleweed. I already had all pipewire user sockets and services disabled and pulseaudio enabled, also de-installed pipewire-pulse as that one is the problem I believe (but is more than a year ago I looked at it). Now it turns out that doing 'pactl load-module module-zeroconf-discover' did add remote audio sinks. GUI based paprefs in Ubuntu/Debian should do it, but that is all grey since years, cannot be selected nor changed. So NanoPi-R6C with Armbian Trixie edge kernel now also plays audio via Armbian Trixie NanoPi-NEO SPDIF enabled with long simple wiring to an amplifier that takes coaxial SPDIF as input. I also had it working analog, but way too much issues with noise etc. 'the long simple wiring' is 1 lead of a low-quality twin analog audio cable, shielding=GND, core=signal.

I think @NicoD meant tasksel.

@fabiobassa thank you, it is worth a try.

For rocket support you need at least 25.3. RTFM

debug boot issues: https://debug.armbian.de

I tried Dragon Quest 11S with stripped dxvk 1.11. It failed because the panvk driver does not support Geometry Shader. There's an on-going MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38401 to support it.

Hi @Scott Ksander, Can you share on which I2C bus the RTC was detected? On my Nanopi Neo3 it was on i2c0, but I see in the meson DTs that RTC is on i2c2. Perhaps you can start with a barebones overlay and add until it starts to work. /dts-v1/; /plugin/; / { fragment@1 { target = <&i2c2>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8563@51 { compatible = "nxp,pcf8563"; reg = <0x51>; status = "okay"; }; }; }; }; Groetjes,

Hello! First of all, thank you robertoj for this treasure trove of information - truly, I searched so much of the internet before finding this, because seemingly nobody is sharing DTS files for tft screens at all that aren't on a raspberry pi (which uses a different system afaik). I am using a rockpi 4bplus, trying to get an ili9488/86 tft screen to work, and struggling. I've used your latest DTS from page 1, using panel-mipi, verified it loads into initramfs using your other threads, compiled my own armbian edge on kernel 6.18 (and tried on kernel 6.12), corrected all FDT err not found errors on the DTS for my use case (my gpio numbers were out of scope)... still, all I get on my display is a blank white screen with no dmesg errors or comments about spi, panel etc... ;-; Not sure what else to try at this point. I'll post my files below, along with translated gpio pin numbers: /dts-v1/; /plugin/; /{ compatible = "radxa,rockpi4b-plus", "radxa,rockpi4", "rockchip,rk3399"; fragment@0 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; /* new for linux 6.13 */ pinctrl-0 = <&spi1_clk &spi1_cs0 &spi1_rx &spi1_tx>; /* new for linux 6.13 */ cs-gpios = <&spi1_cs0>, <&gpio4 26 0>; /* lcd, touch chip select */ panel: panel@0 { compatible = "panel-mipi-dbi-spi"; status = "okay"; reg = <0>; spi-max-frequency = <40000000>; width-mm=<84>; height-mm=<56>; reset-gpios = <&gpio4 29 1>; /* taken from rock3c setup, then modified for armbian */ dc-gpios = <&gpio4 28 0>; /* 1 is low, 0 is high */ write-only; format = "b6x2g6x2r6x2"; panel-timing { hactive = <480>; vactive = <320>; hback-porch = <0>; vback-porch = <0>; clock-frequency = <0>; hfront-porch = <0>; hsync-len = <0>; vfront-porch = <0>; vsync-len = <0>; }; }; ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; pinctrl-names = "default"; spi-max-frequency = <1000000>; interrupt-parent = <&gpio4>; interrupts = <21 2>; /* 2 is IRQ_TYPE_EDGE_FALLING pendown-gpio = <&gpio4 21 0>; /* same as interrupt, pulled high */ vcc-supply = <&vcc5v0_sys>; /* Fill in the voltage according to the actual power supply c> /* OPTIONS */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0XFFF>; ti,y-max = /bits/ 16 <0XFFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0XFFF>; ti,x-plate-ohms = /bits/ 16 <400>; ti,swap-xy = <1>; }; }; }; };

Hello all. I have 3 pi5s running Armbian and 1 pc running windows10. Prior to changing from Bookworm to Armbian all boxes would communicate well with each other. Now only windows explorer communicates with the Pis. The Pis do not see each other nor Windows. I tried (almost) everything and nothing works. I could not get/install WSDD >>Package wsdd is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Error: Package 'wsdd' has no installation candidate>> so I installed WSDD2 and made reference to it and still no go. Any solution? Thank you !!

I see on the mint website that there is nothing mentioned about Arm64, so consider mint as 'stay away' if you use Arm64. You have to do it yourself, so I would go for the most integrated solution. Mint is good for x86, because Ubuntu kernel an various proprietary HW, but that is all not the case for an OPi5+. I would take Debian as base and put Cinnamon on it. You can do it yourself by running 'sudo tasksel' or you put EDK2-UEFI v1.1 firmware on the OPi5+ and use https://dl.armbian.com/uefi-arm64/Trixie_current_cinnamon The missing start button might be complicated to fix, it can be due to some tiny error somewhere when you did setup the computer. Maybe a second try it will work, but maybe it is a real bug. I have only ran Cinnamon once for test for 15 minutes or so, it worked, but I use KDE normally, so have no clue where to look to fix it.

Just an information about the `edge` kernel (6.18) when used on the cm3588-nas system. The rtc driver is not initialized on a `poweron`. After a poweron, you will see the following in the log. Nov 11 01:17:10 uhutest kernel: rtc-hym8563 6-0051: could not init device, -6 Nov 11 01:17:10 uhutest systemd[1]: System time advanced to built-in epoch: Tue 2025-11-11 01:17:09 CET If you have `fake-hwclock` running, you will see the following a moment later. fake-hwclock restores the time, but the service will not properly start, because of the rtc device error. Nov 11 01:17:12 uhutest fake-hwclock.sh[461]: Restoring saved system time Nov 20 13:22:43 uhutest fake-hwclock.sh[466]: Thu Nov 20 01:22:43 PM CET 2025 Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Cannot access the Hardware Clock via any known method. Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Use the --verbose option to see the details of our search for an access method. Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Main process exited, code=exited, status=1/FAILURE Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Failed with result 'exit-code'. Nov 20 13:22:43 uhutest systemd[1]: Failed to start Restore system time on boot and save it on shutdown. You would need to restart the fake-hwclock service, if you want that it saves time before the next restart. If you do a `restart` of the system, the rtc device will get properly initialized and time is good. Following is seen in the logs. Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: registered as rtc0 Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: setting system clock to 2025-11-20T12:26:11 UTC (1763641571) Nov 20 13:26:16 uhutest fake-hwclock.sh[455]: Not restoring old system time I have seen the issue right now only with the 6-18-RC kernel. The following patch mentioned here works as a pure workaround. https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/ Lets see how the development of kernel 6.18 goes and if the final version will not have this issue.

Hello SteeMan, Thanks for your answer Its running now And I will browse the getting started pages To get this system running well It seems faster So i hope i can learn a lot at this forum Greetings Herman

Quick update, having sorted this out I went on to install a CanBus device only to have to enable it again, so I'm back to the same delay

current isn't a good option for rk3588/s devices. At this point of time barely any support for this SoC was mainlined. And it seems like later revisions introduced a regression causing a crash. Since 6.18 may become next LTS kernel it will replace current current kernel at some point. So better go for an edge based image instead.

orangepi5 and 6 have nothing in common. double-check what you are actually talking about. Also there is no 0.9.9 rknpu stuff. 5.10 bsp has been abandoned long ago.