Active threads

@Nick A I tried it — I installed everything and created a secure boot image, but it doesn’t even attempt to boot from it. It just goes straight back into Android. Any idea what I might be missing?

I used it once as test. Good thing is it does verification. Hopefully that will help kill the counterfeit SD-card sales and various rubbish SD-card adapters. Bad thing (for me at least) is that there is some image caching option on by default. Good for saving excessive re-downloads, but I did not look how it works and where it is stored. I use differential backups, also via slow/expensive mobile links potentially, so don't want to wast bandwidth and volume on some cache image or chunk of data. To help people with images on this forum, I did run/boot various images as container, can be done with sudo systemd-nspawn -b -i <imagefile> (if rootfs in image is just 1 partition ) You need some working ARM64 computer of course, but that can be the old/running version of the one you want to upgrade. So I suggest you do that, or maybe the build environment cache cleaning fails (your setup). Also you involve an SD-card already. What if that card internal firmware messes up blocks. If you anyhow build image yourself, maybe use Btrfs as rootfs, also make sure U-Boot has option enabled, than you have much better ways to pin-point where the problem is. But you already did bold text for file dates I see, so I guess some caching issue somewhere.

/dev/mmcblk0p1 is a partition that contains the filesystem, not a drive. The drive is /dev/mmcblk0 and because you did a low-level sector by sector (or block by block) copy with dd, it also just has the exact same partition table (MBR-table or GPT). Now in modern Linux and various pre-installed images there are methods (possible) to expand the partition and the filesystem to occupy the whole remaining space. It is easier with MBR-table. If GPT, there is a backup GPT at the end of the disk, so in your case 64G. On the 128G SD-card the space after 64G is then hidden. I usually manage all this manually before first boot, with gdisk, not fdisk. As it is text based, it also works via remote ssh and serial console cable. I also deliberately added a dummy partition (number 3) to RPi images in the past so that the auto-expander could not claim the whole SD-card. If no GUI, a Linux install fits within a few GB, especially if you use Btrfs as filesystem for root and use on-the-fly compression (mount option compress-force=zstd). Then it is about 1GB needed, not 100x more.

apply this patch for a working wifi: diff --git a/extensions/radxa-aic8800.sh b/extensions/radxa-aic8800.sh index e3e99eaa8..7ab721353 100644 --- a/extensions/radxa-aic8800.sh +++ b/extensions/radxa-aic8800.sh @@ -10,7 +10,7 @@ function extension_finish_config__install_kernel_headers_for_aic8800_dkms() { function post_install_kernel_debs__install_aic8800_dkms_package() { - if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 6.20; then + if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 7.1; then display_alert "Kernel version is too recent" "skipping aic8800 dkms for kernel v${KERNEL_MAJOR_MINOR}" "warn" return 0 fi

I have tested the latest build (26.2.0-trunk.668) and found that USB 3.0 is still not operational. Has anyone been able to get this working?

I have an H50-labeled tv box with a different board (T98-3318-V2.3) but with exactly the same problem - no HDMI even though all the software debug traces show that everything video-related gets called and works. I first tried to make it work 5 years ago and failed and a few months ago I revisited it just to see if I can make it work now in the age of AI. I made a really deep dive into reverse engineering it. I rooted the original Android firmware and dumped anything I could, extracted and analyzed with Ghidra the vendor u-boot and kernel (wasn't particularly helpful) and finally managed to execute the u-boot binary in Renode by emulating a lot of hardware stuff with code or by simply replacing functions with successful returns all the way to the point of u-boot displaying the splash screen and with various hooks and warnings about peripheral accesses I collected a comprehensive trace of everything that u-boot was doing, and in that trace, the AI noticed a certain GPIO access and suggested replacing this vcc-host-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x74 0x00 0x00>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_host_vbus"; regulator-always-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; with this vcc-display-en { compatible = "regulator-fixed"; gpio = <0x74 0x00 0x01>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_display_en"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; in the standard rk3318-box.dts which made HDMI work.

If you want snapshots, you can also do it on filesystem level. Look at Btrfs and snapper. While testing HA 2 years ago, I also took the Intel VM image and made it work in a libvirt VM on an Atom J1900 board. Default size was 32G I think, way too big IMO. So I also took a clone of an existing Debian aarch64 VM (runs on RK3588 or BCM2711) and installed HA in there with supervisor method. I use Btrfs as filesystem, so do not take snapshot of VM image, but just Btrfs snapshot of the rootfs in that VM with HA. Also use Zstd compression, so much smaller than that 32G. But as a matter of fact, HA has good internal backup-restore, so that is also very useful, especially moving between Intel HA en Arm HA.

Hello, I made a buld with the vendor kernel for mekotronics R58SV2, and build ubutu desktop Gnome. I definately have no HW decoding since with fhd .mp4 h264 videos the beast runs on 100% cpu all cores what did I wrong? Help appreciated

After installing the latest update, my 3D printer warns about outdated instructions in the MCU and asks to recompile and flash it. What should I do?

This does not support f2fs I guess; standard in U-Boot is only FAT and Ext4 Some never U-Boot builds also include Btrfs. f2fs I have not seens working, but you will need to build a custom u-boot yourself then. Other option is at add Armbian argument to use an extra bootfs, tha will then be FAT or Ext4, so you can still use f2fs for rootfs. I would make U-Boot understand Btrfs and then use Btrfs for rootfs, as for several boards/platforms that is already default (likely only when you use newer/edge/mainline U-Boot).

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

@Werner I imagine there are plenty of people here who could help solve similar problems. In theory, I could provide a pair of an old RPI (master) and a 4A (slave), with the slave serial connected to the master and power controlled via the GPIO, and they are also on the same VLAN. However, if something goes wrong it needs control to the slave's SD card, all I've found is an SD card extender, and it needs something like an emulator that connects to the master via the same USB/SPI.

First: https://forum.armbian.com/terms Second: Provide full logs

Hey tparys! Thank you very much for your reply and apologies for my delay getting back to you. I haven't had much time to play with this board, but lately I've managed to do some very good progress. Basically I've got Armbian 20 Bullseye working with kernel 6.19. that was a victory! Versions that work/don't: [WORKS] Armbian_20.07_Arm-32_bullseye_current_5.7.7_desktop.img (From a MiQi board) [NOPE] Armbian_25.11.1_Tinkerboard_bookworm_current_6.12.58-homeassistant.img [NOPE] Armbian_25.11.1_Tinkerboard_noble_current_6.12.58_minimal.img [NOPE] Armbian_25.11.1_Tinkerboard_trixie_current_6.12.58_minimal.img [NOPE] Armbian_26.2.0-trunk.370_Tinkerboard_noble_current_6.18.8_xfce_desktop.img [NOPE] Armbian_26.2.1_Tinkerboard_trixie_current_6.18.8_minimal.img Armbians 25 up, some times hangs at Starting Kernel, and majority of the times stops at Loading Ramdisk, all of them tested with most of the DTBs provided The android that runs on the other working board has a kernel with version 4.4 Havent test that because I believe it stops earlier than that I have extracted the DTB from the working Android and got a frankenstein EVB DTS working with some of the features. So far I've got working: *4Cores *2GB Ram *Wifi (using rtw8723d_fw.bin ) *Status LED What doesn't work for sure: -Ethernet -FE2.1 USB Hub 2.0 Untested: ? LVDS 1/2 Panel ? EDP 1/2 Panel ? Speaker ? MIC ? SIM Card Module (Attached to the FE2.1 Hub, so defo not working) And maybe some other peripherals that I was not able to test. I'm still to make the FE2.1 USB Hub work as the 4 only USB physical ports are not working. Also ETH has an issue on stmmac that returns the reset value. and this was merged recently to the kernel. (I'm trying to build v6.19 from source with my patch, but thats being painful too ) Here is my stmmac patch: diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 01ede5148163..9f0ee9ea96fa --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3208,8 +3208,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv) ret = stmmac_reset(priv); if (ret) { - netdev_err(priv->dev, "Failed to reset the dma\n"); - return ret; + netdev_warn(priv->dev, "Failed to reset the dma, device will work with reduced throughput\n"); } I have also attached my current DTS built on top of the EVB version based on the Android with logs from both. Once again, thank you very much for your help! Best Regards, Mauricio. Armbian 20 Bullseye booting log.txt Android Boot Full log.txt android_check.dts rk3288-evb-rk808-armbian-fixed36.dts

Finally managed to restore the box to stock official Android firmware, everything works as expected. I also tested a firmware for the H96 Max M1, with this one the WiFi is not working, they seem to use a different wifi chip. Any recommendations on where to start with flashing Armbian on this device?

OMV 8+ doesn't support 32bit architectures anymore (including Helios4). https://forum.openmediavault.org/index.php?thread/58798-helios4-omv-8/ Given it seems to be stuck on kernel 6.6, it does feel like it's on life support unfortunately.

just go threre: https://forum.friendlyelec.com/viewtopic.php?f=93&t=4691

The initrd might be missing needed drivers for you to continue getting console output. Kind of a pain to troubleshoot that. The kernel I linked above is configured so that it should actually boot with no initramfs at all (though that isn't recommended). It obviously can't hurt to try a different PSU if you have one. The device also will do PoE (on the WAN port I believe) which is a nice little feature so you could try that too. The device tree I use comes directly from the linux tree. It is built into U-Boot and then U-Boot provides it to the kernel via standard location as specified in UEFI. It is entirely possible that older kernels might be unhappy with a newer device tree but you really shouldn't be having any issues with 6.18 and newer but they do need to be configured to load the device tree from UEFI. I think that kernel config option is CONFIG_OF.

This week’s Armbian development saw significant enhancements across hardware support and system functionality. The Arduino UNO Q was officially added, along with new firmware and flash binaries for the QRB2210 and QCM2290 variants. HDMI CEC support was introduced for Rockchip RK3588/RK3576 SoCs, while panel compatibility expanded with updates for Raspberry Pi and Hardkernel ODROID-Vu8S. Key kernel improvements included a bump to version 7.0-rc6 and rewritten patches for Rockchip64-6.18. The release also featured workflow hardening, exclusion of unsupported boards, and fixes for USB-C OTG mode on Odroid-M2. These updates collectively strengthen Armbian’s platform stability and broaden its device coverage. ChangesAdd Arduino UNO Q. by @igorpecovnik in armbian/armbian.github.io#268Add firmware for Arduino UNO Q (QRB2210/QCM2290). by @SuperKali in armbian/firmware#123Add HDMI CEC support to Rockchip RK3588/RK3576 SoCs. by @chaitan3 in armbian/build#9622Agatti: add flash binaries for Arduino UNO Q (QRB2210). by @SuperKali in armbian/qcombin#1Arduino logo. by @igorpecovnik in armbian/armbian.github.io#269ch13726a: Added missing MIPI_DSI_MODE_VIDEO. by @kay-lambdadelta in armbian/build#9621config: rockchip64: build Motorcomm YT6801 drivers built-in for OOB Ethernet. by @c127dev in armbian/build#9625drm: add support for rpi panel v2. by @ackPeng in armbian/linux-rockchip#465Exclude end-of-support boards from armbian-images.json. by @igorpecovnik in armbian/armbian.github.io#271Harden data-update-partners workflow. by @igorpecovnik in armbian/armbian.github.io#270mainline: bump edge to 7.0-rc6. by @EvilOlaf in armbian/build#9618Odroid-M2: Add support for Hardkernel ODROID-Vu8S panel. by @mlegenovic in armbian/build#9627Odroid-M2: Fix USB-C port in OTG mode. by @mlegenovic in armbian/build#9633Remove radxa-dragon-q6a from targets-release-nightly blacklist. by @igorpecovnik in armbian/armbian.github.io#267rockchip-vendor: CONFIG_BT_HCIBTUSB=m. by @vidplace7 in armbian/build#9628rockchip64-6.18: rewrite kernel patches against 6.18.21. by @EvilOlaf in armbian/build#9629SpacemiT: Disable k1-usb: add disconnect function support. by @pyavitz in armbian/build#9620View the full article

Thanks for the info to try other options 🙂 Thanks for the tip, I'll try other options 🙂 It worked for: odroid-c4 ... basically, the settings are the same as for the OrangePI3LTS, I'm talking about connecting cables to a 40x2 / 20x2 LCD. The diagram for the BananapiM2pro is as follows: My Winstar 40x2 OLED LCD compatible with drivers: hd44780 / driver: WS0010 is detected in the system as: 3f .................................. sudo i2cdetect -y 0 [sudo] kris: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- .................................. You can also enter the appropriate values yourself in the file: sudo nano /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=meson fdtfile=amlogic/meson-sm1-bananapi-m2-pro.dtb rootdev=UUID=a4fb8074-c453-45da-ab31-4d61dca46cfa rootfstype=ext4 overlays=sm1-odroid-c4-i2c0 sm1-odroid-c4-i2c1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u regards

@tparys Thanks for your precious advices I merged them in one dts. This suppress the dummy rtc0 rplace it by the real ds3231 rtc , and as it's rtc0 linux uses it at boot with out any service or script. the dts : /dts-v1/; /plugin/; / { compatible = "amlogic,meson-sm1"; fragment@0 { target-path = "/soc/bus@ffd00000/i2c@1d000"; __overlay__ { status = "okay"; clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&i2c2_pins>; #address-cells = <1>; #size-cells = <0>; rtc@68 { compatible = "maxim,ds3231"; reg = <0x68>; }; }; }; fragment@1 { target-path = "/soc/bus@ff600000/bus@34400/pinctrl@40"; __overlay__ { i2c2_pins: i2c2_pins { mux { groups = "i2c2_sda_x", "i2c2_sck_x"; function = "i2c2"; bias-disable; drive-strength-microamp = <3000>; }; }; }; }; fragment@2 { target-path = "/soc/bus@ff800000/rtc@a8"; __overlay__ { status = "disabled"; }; }; }; then I set up a basic service to keep ds3231 up to date either by internal system clock or NTP if chrony synchronize with internet extract of syslog : 2026-04-06T10:19:22.245210+02:00 bananapim5 systemd[1]: Started sync-rtc.timer - Run RTC sync every 6 hour. 2026-04-06T10:19:22.248077+02:00 bananapim5 kernel: rtc-ds1307 0-0068: SET TIME! 2026-04-06T10:19:22.248112+02:00 bananapim5 kernel: rtc-ds1307 0-0068: registered as rtc0 2026-04-06T10:19:22.248120+02:00 bananapim5 kernel: rtc-ds1307 0-0068: setting system clock to 2026-04-06T08:19:16 UTC (1775463556) 2026-04-06T10:24:18.665668+02:00 bananapim5 systemd[1]: Starting sync-rtc.service - Synchronize RTC0 avec l'horloge systeme si NTP actif... 2026-04-06T10:24:18.743806+02:00 bananapim5 sync-rtc: NTP actif : mise à jour RTC0 depuis l'heure système 2026-04-06T10:24:18.751001+02:00 bananapim5 sync-rtc: Mise à jour RTC0 depuis l'heure système NTP actif/inactif 2026-04-06T10:24:19.005750+02:00 bananapim5 systemd[1]: sync-rtc.service: Deactivated successfully. 2026-04-06T10:24:19.006443+02:00 bananapim5 systemd[1]: Finished sync-rtc.service - Synchronize RTC0 avec l'horloge systeme si NTP actif. root@bananapim5:/home/gerard# service : root@bananapim5:/home/gerard# cat /etc/systemd/system/sync-rtc.service [Unit] Description=Synchronize RTC0 avec l'horloge systeme si NTP actif After=chronyd.service [Service] Type=oneshot ExecStart=/usr/rtc/sync-rtc.sh root@bananapim5:/home/gerard# cat /etc/systemd/system/sync-rtc.timer [Unit] Description=Run RTC sync every 6 hour [Timer] OnBootSec=5min OnUnitActiveSec=6h Unit=sync-rtc.service Persistent=true [Install] WantedBy=timers.target root@bananapim5:/home/gerard# cat /usr/rtc/sync-rtc.sh #!/bin/bash # sync-rtc.sh # Synchronisation RTC <-> système avec logging # Vérifie si Chrony a des sources NTP actives NTP_OK=$(chronyc tracking | grep 'Reference ID' | grep -v '0.0.0.0') if [ -n "$NTP_OK" ]; then # Chrony OK, mettre RTC à jour depuis l’heure système logger -t sync-rtc "NTP actif : mise à jour RTC0 depuis l'heure système" else # NTP indisponible logger -t sync-rtc "NTP inactif" fi logger -t sync-rtc "Mise à jour RTC0 depuis l'heure système NTP actif/inactif" hwclock -w -f /dev/rtc0 root@bananapim5:/home/gerard# thanks again

@rsbuffalo's Feb 18th post worked a treat for me on my Dragon Q6a (Armbian 26.2.1 trixie, xfce 4.20). Thanks so much for sharing your solution.

@HenricoLegal can you find the wifi chip on your board?

Holy Shit this is great! Finally can get use out of this doorstopper if you continue. Imagine getting MeshCore or Meshtastic installed.