All Activity

OK, good thing I don't give up easily. I found the cause, but now I need to figure out a fix. Using Armbian_23.11.1_Odroidxu4_jammy_current_6.1.63.img I changed the setenv rootdev to a bad UUID. I get the same error as latest image, but cat /proc/modules shows what's happening. Armbian_23.11.1_Odroidxu4_jammy_current_6.1.63.img initramfs loads: Module Function ------------------ ------------------------------------------------------------- scsi_mod Core SCSI subsystem. (Crucial) sd_mod SCSI disk driver (used for all block devices like SD, USB, SATA). (Crucial) t10_pi T10 Protection Information (disk data integrity). crc64_rocksoft_generic CRC algorithm. crc64_rocksoft CRC algorithm. sg SCSI Generic (raw access to SCSI devices). uas USB Attached SCSI (Driver for USB-to-SATA adapter). (Crucial) usb_storage Generic USB Mass Storage driver. (Crucial) scsi_common Common SCSI routines. zram Compressed RAM block device. zsmalloc ZRAM memory allocator. sch_fq_codel Network queue scheduler. Armbian-unofficial_25.11.0-trunk_Odroidxu4_noble_current_6.6.108.img initramfs only loads usbhid. Not sure how nand-sata-install works, but I'm assuming the something is hosed in initrd.img. Maybe @Igor knows where to look. I'm going to see if I can get the SD initrd.img on the SSD.

I have been experimenting with trying to get video acceleration working on the A83T. I can see from /proc/device-tree/soc/... that there is already a video-engine node within the current A83T device tree. It appears to be applied as one of the megous patches ARM-dts-sun8i-a83t-Add-cedrus-video-codec-support-to-A83T-untes.patch. Admittedly this is noted as being untested. In my initially created build via the build framework, Cedrus was not present at all among the list of loaded modules. I addressed this by creating an entry in the Cedrus compatibility table for the sun8i-a83t-video engine drv-sun8i-a83t-cedrus-add-variant.patch It now appears to load but complains about being unable to allocated an SRAM: [ 10.046406] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.046490] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.091215] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.091339] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.419296] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.419597] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193058] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 20.193114] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193322] platform 1c0e000.video-codec: deferred probe pending: (reason unknown) Using both sun8i-a23-a33.dtsi and sun8i-h3.dtsi as points of reference, I attempted to make an SRAM allocation under the system controller but this still appears to fail with the same failure messages. I have double checked in the user manual and VE memory should definitely exist at 0x01D0 0000. arm-dts-sun8i-a83t-add-ve-node.patch I would be grateful for any pointers. Thanks Ryzer

Hi all, and thanks for your incredible work I just received an "X98k pro" tvbox (sold as rk3566 4gb/32gb ) from T*** The box arrives already rooted. Outside : blue info lcd display --> Sdcard ; usb2.0/OTG ; usb2.0 ; usb 3.x --> Optical SPDIF, HDMI , reset hole, power (5v 2A); external antenna female. -> EMPTY SIDE What's Inside the black box SOC : Rockchip RK3566 RAM : 8 Micron Technology (MT) D9QBJ memory chips Wireless : RTL8822cs Ethernet : RTL8211F eMMC : SanDisk China 32G Front lcd display controller : AIP1628 TTL rx tx gnd Device Info HW 5.23 and CPU-z confirm it's a rk3566 4/32, mali g52 Other infos from Device info HW : Device : rockchip X98k PRO ; Platform rk30board Android 11 , Wifi rtl88x2cs, kernel 4.19.232 (ubuntu...) CPU : Rockchip RK3566 BOX DEMO V10 ANDROID Board After installing termux I tried to find this box's dtb, but the only dtb file I found until now is /sys/firmware/fdt. And this is not the right dtb. Anyway, I de-compiled it using dtc to "rk3566.dts". I'd like to try armbian on this box If u wanna know something else let me know. rk3566.dts

root@rk3318-box:~/tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI" -C /lib/modules/6.16.4-edge-rockchip64/build M=/root/tm16xx-display modules make[1]: Entering directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make[2]: Entering directory '/root/tm16xx-display' CC [M] line-display.o /tmp/cc8iv0mf.s: Assembler messages: /tmp/cc8iv0mf.s:8: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:9: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:10: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:11: Error: junk at end of line, first unrecognized character is `L' make[4]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/scripts/Makefile.build:290: line-display.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:2003: .] Error 2 make[2]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:248: __sub-make] Error 2 make[2]: Leaving directory '/root/tm16xx-display' make[1]: *** [Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make: *** [Makefile:46: module] Error 2 fresh install, box T9 rk3328

I'm not sure it's related to your issue, but on some pi's I've seen Ethernet bandwidth issues accumulating over uptime. It was related to only to a part of specific hardware models, so suspect might be related to either hardware or kernel/driver version/implementation. After some tests I've found that the issue affects only per TCP connection downlink bandwidth - UDP does not have limits, as well as uplink TCP, multiple downlink TCP connections bandwidth stacks linearly. The worst bw case I've seen is ~2Mbps per TCP conn. Reboot fixes the issue for a random time (briefly from a few hours to a few months). Sometimes(?) the issue disappears on its own. So far I've not found a fault-proof fix except a reboot, but changing tcp congestion algo is worth to try: # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = reno bic cubic westwood highspeed hybla htcp vegas nv veno scalable lp yeah illinois bbr # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic # sysctl net.ipv4.tcp_congestion_control=bbr net.ipv4.tcp_congestion_control = bbr For tests you may use iperf3 varying -C/-P/-R/..., e.g.: # iperf3 -4 -f m -P 1 -i 0 -t 5 -c IPERF3_SRV_IP --bind LAN_IP -R -b 100M -u # Single connection DL UDP up to 100Mbps for 5 sec # iperf3 -4 -f m -P 1 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R -C bbr # Single TCP conn DL using BBR as a congestion algo ... # iperf3 -4 -f m -P 50 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R # 50 TCP conns DL

this board appears to have effervesced from your repo in this commit, just a few weeks ago. is it maintained elsewhere?

Hello, is BPI-6202/6204 supported? It should have A40I CPU, like the M2 Ultra (which is actually supported)

I finally had the time to get back here and create a script that installs everything I need for SwayWM to work (as per my needs/taste). I installed armbian-minimal and did: sudo apt install blueman fish fonts-font-awesome foot foot-themes \ fuzzel gvfs hicolor-icon-theme libspa-0.2-bluetooth lm-sensors lxpolkit \ mako-notifier mesa-vulkan-drivers polkitd sddm sway sway-backgrounds \ swayidle swaylock thunar thunar-archive-plugin thunar-volman vim waybar \ wireplumber pipewire-pulse wlogout xarchiver xdg-desktop-portal-wlr \ xdg-desktop-portal-gtk xwayland upower There are lots of dependencies installed, but that's what I needed for my installation. I'm looking where to add this so I can automatically build my version with it without the need to run this command after I install Armbian.

That sounds good 😃, but is it very risky without a full backup? Or can I save same special files/directories in case of a system crash? I have waste a lot of time with the raspberry because of many problem. Therefore, I'm a little bit fearful.

./compile.sh BOARD=orangepizero3 BRANCH=current RELEASE=trixie BUILD_MINIMAL=yes KERNEL_CONFIGURE=no https://docs.armbian.com/Developer-Guide_Build-Preparation/ replace BRANCH with edge if you prefer more recent kernel. replace RELEASE with noble if you prefer Ubuntu flavour. remove BUILD_MINIMAL=yes to get the choice to build a standard cli image instead of minimal/iot.

The Trixie-based XFCE image seems to work fine too, so only the Noble-based images seem to be broken.

yes

Very good, thank you very much. Stupid question – I have a Raspberry pi5 and the manual mentions rpi4b. Will that work?

Collabora and MediaTek are advancing upstream Linux support for the latest Genio IoT boards and Chromebook Plus laptops, enabling full hardware functionality, improved security, and broader access to the open source community. View the full article

The following is documented: But nobody seems to read the docs.😪 Raspberry Pi

@sunshine sorry it didn't work, I though the upgrade for `raspi-firmware` would force the uninstallation of the (outdated) libs, but this doesn't seem to be the case.

No it is not.

I've learned that I can pass BRANCH=vendor and I can confirm that everything works with the vendor 6.1.x kernel. I'd rather not be stuck with this old version but just wanted to confirm that it works with my setup.

I can report back that the above mentioned HAT works well well with the Kioxia SSD I have. So this problem very likely has something to do with armbian, and is not hardware related.

Hi friends, could anyone tell me if Armbian is compatible with S905X5M? Thanks. Regards.

All the while the Raspberry PI OS (version September 2025) has booted out of the box on the board itself. I will check it with with the HAT added too.

OK. I tried it without a backup and I still get an error.

Hi everyone, I'm using the Orange Pi Zero 3 and would really appreciate a lightweight desktop image with just the XFCE desktop, a web browser, and basic tools (like file manager, terminal, etc.) with video acceleration. The current Armbian desktop image works, but it includes a lot of software I don’t need. I’m looking for something more minimal — just enough for light use and a faster experience. Does anyone have (or know how to build) a stripped-down XFCE image for this board? Thanks in advance!

Where did you hear that ? Note that the 'firmware' package is not updating the EEPROM that's present on a Pi4/Pi5 and I had no booting issues updating the raspi-firmware package on RaspiOS.\ Of course you could make a backup if you want to feel safer, but I have no reason to believe there's anything that's going to cause issues if you're going to upgrade the raspi-firmware package.

Thank you very much for the tip. I have heard that one should avoid updating the firmware if possible. Of course, I don't want my entire system to stop working afterwards. Can that happen? Should I make a complete backup before?