All Activity

Thanks for the reply! I'll address everything one by one: I am using the generic red ili9488 3.5inch TFT available everywhere, in this case at this link. I also have a generic red ili9341 2.4 inch TFT I purchased years ago to also test with. Neither seem to work with the DTS. It is definitely not the blue 3.5 inch waveshare screen which looks significantly different. Yes, uboot messages through serial console confirm my dtbo is found and applied without errors. No FDT errors. Applying user provided DT overlay spi1-correctedgpio.dtbo panel-mipi-dbi.ko exists in /lib/modules on the custom compiled armbian running kernel 6.18, but not on the unmodified armbian provided image running kernel 6.12. When building armbian for panel-mipi I confirmed it was selected and it was marked "M" according to the github instructions. Here's the interesting one - basically every GPIO is unclaimed including the ones I have hooked up for the display when doing Here's the link to the rock3c DTS I'm referencing. The Rock 3 pins are named very differently so I translated as best as I could to my rock 4, but I believe they are correct as I found that Radxa distributes a waveshare clone DTS for the rock pi 4 and the pins are named as I have named them. I've pasted the waveshare clone DTS distributed by Radxa below for reference. Using MOSI and MISO do not work, and according to the waveshare DTS I should be using spi_tx and spi_rx. Will continue trying MISO and MOSI in future edits though as it doesn't hurt. You mentioning the waveshare display made me look into the DTBO distributed by radxa OS, I copied it to armbian and tried using it with the red display, and while it expectedly does not work, the pins I expect show up EXCEPT for touch IRQ, which is still unclaimed. I labelled touch, DC/RS, and reset pins for ease of reading in parenthesis. This makes me think I might have success formatting your ili9486 DTS to be similar with the waveshare DTS to get panel-mipi-dbi working on my red LCD. I get dmesg messages so its definitely closer. Here's the full waveshare DTS, note because I decompiled the DTBO with the dtc command, it looks like it lost the target pointers so I'm unsure (but can guess) what they point to. The GPIO pins are also lost but I know what pins they refer to as their pin number is in hex and I can narrow them down to the only pins available according to the pinout diagram. This doesn't affect the DTBO function as I paste the DTBO directly without decompiling, so in theory that should be unchanged and fully functional. At the very least, it claims the GPIO correctly.

@thanh_tan You found one armbian image to boot on Orangepi4A?

Still not. Debian starts to load but then gets stuck (see photo above). I have tested again with a bookworm image and it worked. So there may be something wrong with the trixie image unfortunately 😕

We don't deal with Android here. Ask vendor or at some place like xda developer forums.

Hi @djurny, Yes it’s nice to tinker just so busy/tired that I’m not even doing that on the Windows side anymore. Still like the helios64 and would love to bring it up and running stable when needed, was just curious if worth the effort so looking for some success stories. I only plan to use it as a handy backup device which does sound strange for something unsupported. I think I’m still on buster as well on the sd card and never had the instability issues discussed around here (I think I mostly let it run 3 or 4 days at once in the first couple of years just to see if anything happens and did not). But I do read around here every couple of weeks. Thank you for your time!

Try from here: https://fi.mirror.armbian.de/dl/rock-5b-plus/archive/

I can't mount the SD card to do the modification... It says the GPT table is corrupt. Well that may explains why belenaEtcher throws an error. I used USBImage instead, it doesn't throw an error but the main GPT table is still corrupt. I have tested with 2 different SD cards. I believe there is a problem with these Trixie (Desktop) images for Rock 5b+. (Yes I have checked the checksum after the download) I'm currently downloading the older bookworm image to check if it works, and that there is no hardware issue.

hello please need the stock firmware to reflash please

edit /boot/armbianEnv.txt and set verbosity to 7 to get an idea about what happens inside.

I have erased the SPI ROM. It boots from the SD Card now, thanks :-) But now I have another problem 😕 It boots, it start to load Trixie, but after 30s it get stuck here:

This should work too. Debug boot issues: https://debug.armbian.de Related perhaps: https://github.com/armbian/build/pull/8994

Logs from what? It doesn't boot from SD, I have a blank screen. Should I erase the SPI ROM to make it boot from the SD again? https://docs.radxa.com/en/rock5/rock5b/low-level-dev/install-os/rkdevtool_spi

Can you provide logs?

But it doesn't boot from the SD card anymore 😕 The bootloader is expecting the OS on the NVME drive.

Just boot from microsd and then use armbian-install to move image to spi/nvme directly attached?

Hello I have burned bookworm onto a sd card,booted on it with a Rock 5B+ and installed the bootloader on the SPI flash of the board and transferred the OS to the nvme drive. Now I I'm trying to install the new trixie image, but I can't burn it on my nvme drive. With USBImage it does not work. It doesn't detect my nvme drive installed on my USB adapter. With belena Etcher it throws an error during the validation of the image. Win32Imager doesn't load at all on Windows 11. I don't know which other tool (Windows) I could use. I'm stuck. How can I boot again from my SD card on a Rock 5b+?

I used the latest official image for a brand new install and set up OMV afterwards. So far everything works, but I ran into the "sata-reboot" bug. That said: Once I reboot after an update for example the sata drive is not being recognized. M2 nvme does come up as usual but not the sata ssd. Only remedy: Shutdown the M1, unplug, replug power cable and this cold reboot does the trick and the sata drive comes up again properly. It seems to be a kernel bug somehow and via armbian-config I tried several kernels but the bug unfortunately persists. Any ideas?

I tried several options, each time on a clean system. 1) echo "deb http://apt.armbian.com bookworm main bookworm-utils" | sudo tee /etc/apt/sources.list.d/armbian.list wget -qO - https://apt.armbian.com/armbian.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/armbian.gpg sudo apt-get update sudo apt-get install make sudo apt-get install git sudo apt-get upgrade sudo reboot sudo apt install linux-headers-current-meson64 -y git clone https://github.com/xProbe/aic8800d80-wifi-driver.git sudo cp aic.rules /lib/udev/rules.d/ sudo cp -r ./fw/aic8800D80 /lib/firmware/ cd ./drivers/aic8800 make sudo make install sudo modprobe aic8800_fdrv lsmod | grep aic Вывод aic8800_fdrv 499712 0 aic_load_fw 65536 1 aic8800_fdrv cfg80211 385024 3 mac80211,rtl8xxxu,aic8800_fdrv dmesg выдаёт: [ 14.463892] Bluetooth: hci0: command 0xfc18 tx timeout [ 14.471627] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 14.477696] Bluetooth: hci0: Failed to set baudrate [ 14.765636] wlan0: authenticate with 58:f8:5c:58:72:6c (local address=00:c6:a 2:25:44:eb) [ 14.770507] systemd[1]: Finished armbian-ramlog.service - Armbian memory supp orted logging. [ 14.772632] wlan0: send auth to 58:f8:5c:58:72:6c (try 1/3) [ 14.783084] wlan0: authenticated [ 14.791828] wlan0: associate with 58:f8:5c:58:72:6c (try 1/3) [ 14.796409] wlan0: RX AssocResp from 58:f8:5c:58:72:6c (capab=0x411 status=0 aid=4) [ 14.803902] usb 1-2: rtl8xxxu_bss_info_changed: HT supported [ 14.809513] wlan0: associated [ 14.809799] systemd[1]: Starting systemd-journald.service - Journal Service.. . [ 14.972227] systemd-journald[1340]: Collecting audit messages is disabled. [ 15.122032] systemd[1]: Started systemd-journald.service - Journal Service. [ 15.252235] systemd-journald[1340]: Received client request to flush runtime journal. [ 15.342582] systemd-journald[1340]: /var/log/journal/d44cb1f74dea4809a2af30db 6816ca18/system.journal: Realtime clock jumped backwards relative to last journa l entry, rotating. [ 15.410914] systemd-journald[1340]: Rotating system journal. [ 16.511866] Bluetooth: hci0: command 0xfc18 tx timeout [ 16.514129] Bluetooth: hci0: BCM: Reset failed (-110) [ 17.317977] systemd-journald[1340]: Received client request to relinquish /va r/log/journal/d44cb1f74dea4809a2af30db6816ca18 access. [ 950.587521] aic_load_fw: loading out-of-tree module taints kernel. [ 950.600781] aic_bluetooth_mod_init [ 950.606085] RELEASE DATE:2025_0423_71b66e7b [ 950.611193] AICWFDBG(LOGINFO) aicwf_prealloc_init enter [ 950.635622] AICWFDBG(LOGINFO) pre alloc rxbuff list len: 1000 [ 950.640969] usbcore: registered new interface driver aic_load_fw [ 950.678054] AICWFDBG(LOGINFO) rwnx v6.4.3.0 - 1a4b0054d2M (master) [ 950.680449] AICWFDBG(LOGINFO) RELEASE DATE:2025_0423_71b66e7b [ 950.686449] usbcore: registered new interface driver aic8800_fdrv 2) 3) 4) I tried it, it didn't help. 5)

And further, what do you need? I know Armbian and Opensuse use chrony instead of older ntp things. Chrony can serve the time to others, do you need that? If not remove it I would say and keep/use a standard client-only method.

2 captains on the same ship is my first note. Then there is fake-hwclock and maybe an RTC onchip/silicon and/or your own or PCB vendor added RTC module like DS3231. And the battery can be almost empty. Early Debian Trixie had a bug with fake hwclock script, I already removed it years ago on SBCs where I added DS3231, but if you haven't there is the sort of 3rd captain. RPi/Raspbian users had that issue.

keep pushing, this device is not brickable, you can make your trip worry-free

I think it still makes sense. And in the off chance that you DO find you have some time leftover, it's also nice to tinker and hobby about with. Mine is still running Buster and has not missed a beat since I got the thing - besides some issues with the SATA connector on the top drive and the inability to upgrade RAM. Groetjes,

Can anyone tell me if it's possible to install renegade firmware on a Rasperry Pi build for example? Libre used to host a script for a tool that achieved this but it hasn't been updated since Buster TIA

We don't support 3rd party forks. Ask at the place where you got this OS from.

Hello, I am using an X96 Air (S905X3) with Armbian (6.1.127-ophub) and I can see the hardware decoder working: v4l2-ctl --list-devices Amlogic Video Decoder (platform:meson-vdec): /dev/video0 However, the hardware encoder (VENC) does not appear: ls /dev/video* /dev/video0 ls /dev/amvenc* ls: cannot access '/dev/amvenc*': No such file or directory I want to use ffmpeg with hardware encoding (h264_v4l2m2m) for real-time RTMP streaming, but without the encoder device, it is not possible. Could you please explain: Does this kernel support VENC on S905X3 at all? If not, what changes are required to enable hardware encoder in the kernel? Is there any instructions or topics ? Any guidance or examples would be very helpful. Thank you!