All Activity

Hiya, I am currently trying to setup some ROCK 5B boards as runners and as I install the latest Ubuntu 24.04 (Noble) from here https://www.armbian.com/rock-5b/ it seems to get to where I configure my user etc, then on the next boot it gets stuck at kernal. So I guess before I go through trial and error , is there a recognised most stable build that can be relaibly flashed people would recommend, I found the Rock provided Debian and KDE Plasma to be very buggy and just kept locking up on me so something with Gnome would be cool for now , but will probably move to headless much further down the line. Amazing community reading the messages so far so thank you for everyone who contributes!

@fabiobassa thank you, it is worth a try.

For rocket support you need at least 25.3. RTFM

@dale as usual shorting pins 6/7 on the well exposed nand

If I remember correctly to actually use the NPU you'd need a 6.18-kernel and a recent Mesa version. Compared to the standard 24.0.x Mesa version in Debian Trixie I though you needed 24.3 or 25.0. But if you actually tried working with it, you should be able tell what you are using.

@王类 here are instructions to build an armbian image with maxio kernel module. It applies to current LTS kernel version 6.12.58. Its mostly cut and paste and uses windows so I hope you can try this! @maka I'll keep working on your suggestions. Many thanks! my_board_df.dtb maxio_install.pdf

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

taskset is not found in the repository. I have resolved the issue by install xubuntu-desktop package rather than installing xfce4 and xfce4-goodies. Thanks for the help. ref:

Thanks. I got pulseaudio working

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,

Some more info, I found a lot of DT entries for the PCF8563 in a recent codebase for some of the Amlogic SoCS, but not the C2. What is shown are: HC4 M2 Perhaps you can check if those overlays are compatible with the C2 and experiment a bit? Groetjes,

Thanks. Will give that a look Scott

Hi @Scott Ksander, `i2cdetect` will just detect stuff on the I2C bus, you would not need a DT overlay for the device for that to work. For the kernel to detect the device and load the appropriate kernel module for it, you do have to make sure the device is known in the DT. I'm not sure about your board, but for a PCF8523 (different RTC) my Nanopi Neo3 I had to add or adjust an existing user overlay to make the PFC known to the kernel. /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; pcf8523@68 { compatible = "nxp,pcf8523"; reg = <0x68>; status = "okay"; }; }; }; }; &rk805 { rk808-rtc { status = "disabled"; }; }; For a DS3231 I also had to add a user overlay that would tell the kernel that it can use the DS3232 driver for a DS3231 device. You most likely already found all the information on this already on the interwebs. You will have to adjust the compatible entry to your board, you might even try without that line completely. Add the file to `/boot/overlay-user/` and then compile and add to `armbianEnv.txt` using `armbian-add-overlay`. Groetjes,

No errors are logged. Overlays are i2cA and i2cB. Module is rtc-pcf8563. No /dev/rtc* is created i2cdetect -y 0 shows 0x51 thanks

Hi @Scott Ksander, Can you share a little more information? Like what errors are logged, which commands you tried to use, what DT and overlay you tried,etc. Thanks,

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>; }; }; }; };

I am unable to get any RTC installed on a C2 with current Armbian. i2cdetect sees the device ID but no joy getting anything to talk to it. Yes, I know these are very old but they were donated to a non-profit and I am trying to help set them up for a project. Current Armbian runs great and perfect for our need. I need an RTC. I have tried both the Odroid PCF8563 (0x51 seen) and DS3231. I have tried all the online blog posts, rebuilt the Device Tree, etc. but can't seem to get things to work. Any pointers would be much appreciate. LInux odroidc2 6.12.56-current-meson64 #1 SMP PREEMPT Wed. Oct 29 13:09:02 UTC 2025 Thanks, Scott

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 have tried to download at least 3 times this image: Armbian_25.8.1_Orangepi5-plus_noble_vendor_6.1.115_gnome_desktop.img.xz All sha256sum verified Ok. And wrote 5 times on 3 different SDCards, and this img does not boot on my OPI-5-Plus. No image on monitor, partition armbi_root not expanded, no green lights... Just unusable (for me). Other img's that boot are OK: Deb-xfce, noble-cinnamon, noble-neon... Someone got success with this img??? I'm looking for a distro that works well on OPI5-Plus, well configured, and that works with HDMI audio. The best for now is Noble-Cinnamon but failed to setup Menu button, and I cant find support until now to solve this issue. Thanks, Cury

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.

My post on Mint Forum was rejected: Somebody knows were Can I get support for Cinnamon on Armbian distros???

Hi all, I decided to revive my old rk3229 board with NAND. Could someone please tell me how to unbrick 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.

Is there any chance of this image running on a device using the RKPX30 chip? From some research, it seems to be a variant of the RK3326, and I'm not sure how similar the 3328 and 3326 are or are not. Or is there another Armbian image for the RKPX30/RK3326? Specifically looking to run Armbian on this: https://docs.revrobotics.com/duo-control/control-system-overview/driver-hub-specifications