Active threads

FYI: The following refers to a supervised installation done with armbian-config (starting from "community_25.5.0-trunk.370"). Not sure if the ready homeassistant Armbian images behave differently. Before apt-upgrading the system running homeassistant (supervised), I recommend a) doing a full image backup and b) locking homeassistant-supervised ("apt mark hold homeassistant-supervised"): Updating homeassistant-supervised with apt-upgrade first showed a selection box of the used hardware (none of them matched my rockchip64/rock 4c+ AFAIK - in despair I chose qemu-aarch64), afterwards homeassistant went into first initialization setup (the "wait ~20 minutes to set up" message). Not sure, if it would have somehow fixed itself - I reverted to the (full-image) backup once I saw that message. Having locked the supervised package beforehand, "apt upgrade" was able to update the system without breaking homeassistant (at least it looks like that so far).

git clone --depth=1 https://github.com/armbian/build.git cd build ./compile.sh build BOARD=rk3328-heltec BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=no KERNEL_CONFIGURE=yes KERNEL_GIT=shallow RELEASE=bookworm Can you help me take a look, right? Clone the library in this way, and then compile it

@rickg i send you a private message

Apparently the compile script or one of its libraries uses a fixed DNS server instead of the DHCP provided one. After disabling some pfSense rules I was able to successfully boot. However, it seems like still 2GB RAM is incorrectly shown: _ _ _ __ __ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ ___ _ _ _ _ ___ / _|/ _(_)__(_)__ _| | / _ \| '_| ' \| '_ \ / _` | ' \___| || | ' \/ _ \ _| _| / _| / _` | | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| \_,_|_||_\___/_| |_| |_\__|_\__,_|_| v25.08 rolling for Orange Pi Zero3 running Armbian Linux 6.12.30-current-sunxi64 Packages: Debian stable (bookworm) Support: DIY (custom image) IPv4: --- Performance: Load: 20% Up time: 1 min Memory usage: 7% of 1.93G CPU temp: 45°C Usage of /: 9% of 15G Also, /dev/ttyS1 is not working, I used overlays=uart5 which enabled /dev/ttyS1 correctly using Armbian Debian Minimal image from the Download section. dmesg does not output anything related to ttyS1.

This reminds me of old issue on rpi forum, back to Debian10 times more or less when RPL did not support initramfs and I have been using Btrfs for RPis since Buster (or for sure Bullseye) timeframe. I loop mounted Armbian rolling rpi4 trixie image and ran it via systemd-nspawn -b -D <mountpoint> Then it turns out what I thought: the installed firmware package includes the script same as on Raspberry Pi OS from RPL themselves to copy/rename standard Debian kernel+modules install patch to the FAT boot partition. root@localhost:~# apt list | grep raspi raspi-config/trixie,trixie,now 20221214-0ubuntu1 all [installed] raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-gpio/trixie 0.20231127 arm64 raspi-utils/trixie,trixie 20250314-1 all root@localhost:~# dpkg -L raspi-firmware | grep z50 /etc/initramfs/post-update.d/z50-raspi-firmware /etc/kernel/postinst.d/z50-raspi-firmware /etc/kernel/postrm.d/z50-raspi-firmware And it is this part of z50-raspi-firmware flavour="$(echo "$initrd_version" | rev | cut -f1 -d- | rev)" case $flavour in v6|v7|v7l|v8|2712) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac On 1 of my RPi4 I had also the standard Debian kernel 'linux-image-arm64' besides the RPi kernel 'linux-image-rpi-v8' and grub-efi. So when the bootFAT parttition is tagged 0xEF00 (ESP) I could run the image/SD-card unmodified in virt-manager selecting the vanilla Debian kernel in GRUB. I have thought a lot about what to do with those hook scripts in /etc/initramfs, also created various own ones, for Raspberry Pi OS and Raspbian and Armbian. The latter as it is U-Boot (on Rockchip/Allwinner) but just recently I put EDK2-UEFI v1.1 in SPI-flash and that makes all the efforts void as I now use default grub to load Armbian (and Opensuse) on RK3588. For RPi (3, 4, 5) this won't work unless some intermediate efi binary loader is used like is done in Opensuse, for Fedora maybe as well, I don't know. Still this won't work for RPi5 (yet) as its RP1 chip is a bottleneck for upstream support (complex PCI-E DeviceTree handling, see patches efforts done by Suse people AFAIR). With introduction of Bookworm, the RPi firmware can load standard names for initramfs for all RPi HW variants back till 2012. But still no way to select a specific kernel adhoc at boot time via serial console for example (like extlinux.conf for U-Boot). The U-Boot v.s. RPI-firmwarebootloader feels a bit like UNIX pathnames v.s. MS-DOS pathnames, e.g. "/tmp" v.s. "C:\TEMP" or "Image" v.s. "kernel8.img" or "uInitrd" v.s. "initramfs8". Maybe the option is to patch z50-raspi-firmware, maybe remove it from the .deb package. But also it is just a warning, so who cares one could think. Other option is to use the vanilla Debian variant of raspi-firmware root@localhost:/etc/apt/sources.list.d# apt list -a raspi-firmware raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-firmware/testing 1.20240424+ds-6 all That older version has other script implementation (very different), also uses upstream_kernel=1 in config.txt, which selects other firmware DTB names for Pi3. Now writing this, I think 'vendor' could be downstream RPL based, so new firmware package and 'current' and 'edge' could be upstream mainline. But that also would mean almost no RPi5 functionality as long as that RP1 I/O chip functionality is not upstreamed. I don't know what status is, latest I know is that the wired ethernet still does not work, workaround is to use a RJ45 USB2 dongle on the USB-C connector.

I don't know if this method works for rknpu enable @Hqnicolas https://github.com/armbian/build/blob/e03b1b543cda430fbffcb62c979aecabee42b044/patch/u-boot/v2024.10/board_orangepi3b/0001-rockchip-rk3566-orangepi-3b-enable-npu-regulator.patch#L4

Interesting, didnt realize that.

Thank you for reporting. If current images have troubles, you can try to use previous ones. There is a link on the download pages or you can find them this way. https://forum.armbian.com/topic/52406-helios-64-fails-to-boot-since-upgrading-to-bookworm/#comment-219614 Which works best for your case, you will need to find on your own. We don't store this information / forum search might help. Similar goes with 3rd party images - most are Armbian based and none is in perfect state, things break apart all the time. By providing logs (if possible) someone might give you hints to workaround the problem, without hardly. As I understand from your report - image boots, but USB port doesn't work to enter password? And also network is down, so you can't login remote. I haven't tested HC4 on last builds, but C4 works just fine. In any case, fixing the problem can take some time - Hardkernel never supported our work, so we don't have active maintainer at stand by. It depends on volunteers that read this forum. When they notice and found time to look into this.

As the Armbian project transitions from spring into summer, the final week of May 2025 brought a dense flurry of development activity, delivering improvements across kernel support, bootloader updates, system performance, and user experience enhancements. With over 35 pull requests merged, this week showcased the Armbian community’s continued dedication to modernizing and stabilizing its build framework and board support packages. Performance & Build System Optimizations A notable performance enhancement arrived via #8248, where build engineer @rpardini delivered a major speed-up in Docker extension handling, cutting processing time by over 50%. Complementing this, PR #8249 addressed inefficiencies in rootfs-to-image by avoiding --sparse, significantly improving I/O speeds on various filesystems. Kernel version parsing and custom kernel description functionality also landed with #8152, thanks to @Grippy98, enabling displaying kernel versioning within build branches. Board Support Enhancements & Bootloader Upgrades A slew of boards received attention this week. The NanoPC-T6 series saw a key modernization in #8219 and #8239, switching to mainline Arm Trusted Firmware and bumping U-Boot to v2025.04 final. The Quartz64A board followed suit in #8250, while the Odroid HC4, Khadas VIM3, and Mixtile Blade3 all received U-Boot updates or reverts to improve stability. Legacy and edge kernel support was also improved. Notably, Rockchip64 edge kernel configuration gained CONFIG_NETKIT=y (#8237), and fixes for display mode handling on RK3588 boards were added (#8253). Meanwhile, the Orangepi 5 Ultra switched to a mainline kernel source (#8252), reinforcing Armbian’s ongoing effort to shed legacy components and embrace upstream compatibility. Infrastructure & Usability Improvements Behind the scenes, @igorpecovnik contributed multiple usability tweaks, including a fix for HiDPI detection (#8236) and @rpardini added improved serial console fallback behavior in GRUB (#8247). The GPG key placement was standardized across distros (#8128), simplifying build reproducibility. Device Tree and Service Fixes The smart am40 received a long-needed RTC node and U-Boot bump (#8214), while the Helios4‘s wake-on-LAN service was fixed (#8235), reinforcing Armbian’s commitment to community-requested board maintenance. Wrapping Up This week’s burst of activity highlights the Armbian community’s tireless commitment to refinement and modernization. Whether through performance enhancements, kernel bumps, or quality-of-life fixes, the project continues to evolve rapidly. Users can expect a more responsive, stable, and future-proof experience across a growing roster of supported hardware. Stay tuned for further updates as June unfolds. The post Armbian Development Highlights: End of May 2025 first appeared on Armbian. View the full article

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-install should be able to do that. Though since there is no option to select WHICH version, if there are multiple installed, to write, I suggest to first check with code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg -l which uboot package/s is/are installed and make sure there is only the one that you want to write.

config is there: https://github.com/armbian/build/blob/main/config/boards/orangepi5-ultra.csc DIY: https://docs.armbian.com/Developer-Guide_Overview/ Go for edge

Hi @gyrex, You might want to try without the fstab entry for your root filesystem: UUID=024728b4-7d81-4433-8476-0f98407d1481 / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1 and add the following to your armbianEnv.txt. extraargs=rw The fstab entry for your rootfs is there to remount your rootfs with some options, it is not there to actuall mount it - that's already done by the rootdev/rootfstype in your kernel commandline. or: change the last digit from 1 to 0 in the fstab entry for your rootfs to prohibit fsck during boot. Hopefully that would allow the system to complete it's boot and make room for some live troubleshooting. Thx, Groetjes,

look here https://github.com/hzyitc/armbian-onecloud/releases

Did anyone managed to boot anything other then android on TX6S?

Yes, the rock5b work just fine. I also installed the UEFI into the SPI there (I have 2 Rock 5b) - I might want to give the itx a shot installing the UEFI into the SPI one day. There is something in the UEFI image which does not boot from SD; trying to find any docu about that - I came across one article mentioning some HW hack to change the boot order (probably what you described up there). The 5b and itx are quite different (itx is also 10-20% faster with higher clocks and faster RAM) but otherwise once the UEFI is installed, mine run the same OS. Unfortunately to run ACPI one needs a latest OS (Ubuntu 25 or Fedora Rawhide) - I haven't actually tried the mainline Armbian - I run KDE Plasma and while there was a Neon image somewhere most Armbian prebuilts don't run KDE (everytime I post install that, something else breaks). Anyway, I am happy that everything is working now on all my Rock5 boards.

EDIT: Actually, armbian can't be installed with PhoenixSuit, I didn't know :/ I've already tried several images, 5+, but this error keeping appearing. Also, I would like a bookworm image for Allwinner H3Q44, if someone have one working good, please send it to me. UPDATE: This random img worked.

This fixed the issue with Chromium. I simply created a file /etc/armbian/cromium.conf with the contents you provided and chromium opened perfectly.

The same issue with Kernel 6.12.23, my flashdrive can not be found. Kernel 6.6.75 is still doing its work

Armbian packages get updated now, so now upgrading to 25.8.0-trunk.100, from .87 I did earlier yesterday. Also now running 6.15.0-edge-rockchip64 with EDK2-UEFI v1.1 in SPI. Need setting to DeviceTree as the default (Both = ACPI and DeviceTree) seems to confuse 6.15.0-edge-rockchip64, got only serial console only or stall somewhere in boot process.

Jens J, woah, I didn't know that you can just split bootloader like that! I did that, and so far, it looks good! TV Box boots into u-boot with this SD card, and it has a partition table. Thank you so much! Now I'll try to make an SD card with system on it

@ovacikar Did you manage to get this fully working? What does this kernel bring? I saw recently hw acc is now working, did you manage to get this working? Im asking because this weekend im going to try to get mine all up to date and see if i can get it be a simple media player

Have you tried `/boot/dtb/amlogic/meson-gxm-mini-m8s-pro.dtb` ? What is wifi chip? Is it LTM8830? If so this is QCA9377 clone, and this dtb should be fully working.

Hi everyone, I’m working on a custom Armbian build for an RK3588-based board (cm3588-nas) and trying to completely disable the Rockchip crypto driver (rk_crypto2), since it's negatively impacting LUKS (AES-XTS) performance. Despite several attempts, the module continues to register algorithms in /proc/crypto after boot: driver : rk2-sm3 module : rk_crypto2 driver : rk2-sha512 module : rk_crypto2 driver : xts-aes-rk2 module : rk_crypto2 ... ------------------------------------------------------------ What I’ve Tried ------------------------------------------------------------ 1. Kernel Config Override - Added CONFIG_CRYPTO_DEV_ROCKCHIP=n and CONFIG_CRYPTO_DEV_ROCKCHIP2=n to: userpatches/linux-rockchip-rk3588-edge.config - Verified .config has it set to n after build. - Used CLEAN_LEVEL="make,debs,oldcache" in the build command. 2. Blacklisting & Deletion in customize-image.sh echo "blacklist rk_crypto" > /etc/modprobe.d/blacklist-rk_crypto.conf rm -f /lib/modules/*/kernel/drivers/crypto/rockchip/rk_crypto.ko* 3. Post-Boot Verification - lsmod | grep rk_crypto → empty - modinfo rk_crypto → module not found - /proc/crypto still shows rk2-* drivers tied to rk_crypto2 4. Manual Source Removal - Commented out this line in drivers/crypto/rockchip/Makefile: # obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o - Also removed or disabled its Kconfig entry. ------------------------------------------------------------ System Details ------------------------------------------------------------ Board : cm3588-nas (RK3588) Kernel : rockchip-rk3588 edge (Linux 6.8.x) Builder : Official Armbian compile.sh ------------------------------------------------------------ Goal ------------------------------------------------------------ I want to fully disable the Rockchip crypto engine (rk_crypto2): - It should not load, not build, and not register anything in /proc/crypto. - LUKS should fall back to software crypto (cryptd, aesni, or default fallback). ------------------------------------------------------------ Any help is appreciated. I’d love to hear from anyone who’s successfully disabled rk_crypto2 entirely or has ideas for where the registration is coming from even when the module appears removed. Thanks!

Hi @Vodalex, Write down the MAC address of the interface you want to use to wake up the Helios4. ip link show You would need to put the Helios4 in suspend, by either: sudo pm-suspend or: echo 'suspend' | sudo tee /sys/power/state To wake it up, from another system, make sure that wakeonlan is installed. Then: wakeonlan ${HARDWARE_ADDRESS} That should be it. Groetjes,

Did anyone managed to get Linux working on TX6S?