Active threads

I'm flashing the image to a microSD card using Armbiam Imager doesn't boot: works OK:

no, it have secureboot, emcp 1,5gb instead 1 or 2gb ram, i tried to boot x96q lpddr3 + secure patch + orangepi zero3 1,5gb patch but at uboot it allway say 2gb ram 0g effective. uboot spl load 1,5gb ram correctly

Hi @Jean-Francois Lessard Thanks for sharing the new openvfd option for Armbian. I am using a Allwinner H618 Android 12 TV box that got FD6551 controller. I have verified the chip model by opening the box. The headers of respective version is also installed and I have double checked that. apt install -y linux-headers-edge-sunxi64 Reading package lists... Done Building dependency tree... Done Reading state information... Done linux-headers-edge-sunxi64 is already the newest version (25.11.2). From the Android dts file I can find the following. I have tried the configuration mentioned here as well but there is no VFD output. Is there any other configuration I have to check or modify for the VFD to work? leds { leds_clk = <0x23 0x08 0x0b 0x00>; leds_dat = <0x23 0x08 0x0c 0x00>; status = "okay"; }; fd655_para { device_type = "fd655_para"; compatible = "Ik,fd655_dev"; fd655_clk_io = <0x23 0x07 0x06 0x01>; fd655_dat_io = <0x23 0x07 0x07 0x01>; status = "okay"; }; ald-colorleds { compatible = "elebao,colorleds"; dev_name = "ald-colorleds"; pinctrl-0 = <0x70>; colorleds_data_gpio = <0x23 0x07 0x02 0x01>; status = "okay"; }; I tried to make the module as you have instructed, however I am getting the below given error messages. /tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI -include /root/tm16xx-display/drivers/auxdisplay/tm16xx_compat.h -I/root/tm16xx-display/include/" -C /lib/modules/6.12.11-edge-sunxi64/build M=/root/tm16xx-display/drivers/auxdisplay CONFIG_TM16XX=m CONFIG_TM16XX_KEYPAD=y CONFIG_TM16XX_I2C=m CONFIG_TM16XX_SPI=m CONFIG_LINEDISP=m modules make[1]: Entering directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' CC [M] /root/tm16xx-display/drivers/auxdisplay/line-display.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_core.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_keypad.o LD [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_i2c.o CC [M] /root/tm16xx-display/drivers/auxdisplay/tm16xx_spi.o MODPOST /root/tm16xx-display/drivers/auxdisplay/Module.symvers CC [M] /root/tm16xx-display/drivers/auxdisplay/line-display.mod.o In file included from /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:2: /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:41: error: expected ‘)’ before ‘LINEDISP’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:13:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 13 | KSYMTAB_FUNC(linedisp_attach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:41: error: expected ‘)’ before ‘LINEDISP’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:14:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 14 | KSYMTAB_FUNC(linedisp_detach, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:43: error: expected ‘)’ before ‘LINEDISP’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:15:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 15 | KSYMTAB_FUNC(linedisp_register, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:45: error: expected ‘)’ before ‘LINEDISP’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~ ./include/linux/export-internal.h:45:28: note: in definition of macro ‘__KSYMTAB’ 45 | " .asciz \"" ns "\"" "\n" \ | ^~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ ./include/linux/export-internal.h:41:12: note: to match this ‘(’ 41 | asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \ | ^ ./include/linux/export-internal.h:62:41: note: in expansion of macro ‘__KSYMTAB’ 62 | #define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns) | ^~~~~~~~~ /root/tm16xx-display/drivers/auxdisplay/line-display.mod.c:16:1: note: in expansion of macro ‘KSYMTAB_FUNC’ 16 | KSYMTAB_FUNC(linedisp_unregister, "_gpl", ""LINEDISP""); | ^~~~~~~~~~~~ make[3]: *** [scripts/Makefile.modfinal:31: /root/tm16xx-display/drivers/auxdisplay/line-display.mod.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.12.11-edge-sunxi64/Makefile:1870: modules] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' make: *** [Makefile:50: module] Error 2 root@homeassistant2:~/tm16xx-display# make-module install make-module: command not found root@homeassistant2:~/tm16xx-display# make module-install make -C /lib/modules/6.12.11-edge-sunxi64/build M=/root/tm16xx-display/drivers/auxdisplay CONFIG_TM16XX=m CONFIG_TM16XX_KEYPAD=y CONFIG_TM16XX_I2C=m CONFIG_TM16XX_SPI=m CONFIG_LINEDISP=m modules_install INSTALL_MOD_PATH= make[1]: Entering directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' DEPMOD /lib/modules/6.12.11-edge-sunxi64 Warning: modules_install: missing 'System.map' file. Skipping depmod. make[1]: Leaving directory '/usr/src/linux-headers-6.12.11-edge-sunxi64' root@homeassistant2:~/tm16xx-display# make service-install modprobe tm16xx modprobe: ERROR: could not insert 'tm16xx': Exec format error make: *** [Makefile:60: service-install] Error 1

Armbian's next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage class that replaced eMMC in phones, is packet-based and full-duplex with command queuing. The practical gain over an SD card shows up in random I/O, in latency under concurrent load, and in write endurance that holds up over years of deployment. FriendlyElec ships UFS on the M5 because the RK3576 has a native UFS controller, a sensible choice for any board destined for kiosks, robots, or industrial gateways. What mainline was missingThe UFS controller IP itself had a partial driver in mainline U-Boot. Everything around it was not wired: PHY init sequencing, the regulator rails the device needs before it responds, the device-tree glue that tells U-Boot "yes, this board has UFS." For the M5, none of it existed. There is also a cosmetic detail that catches every newcomer, namely that Rockchip's loader tooling labels UFS as SATA in the RKDevTool storage dropdown. Flashing goes through upgrade_tool, not the more familiar rkdeveloptool, because rkdeveloptool has never had UFS support. How it came togetherThree workstreams had to converge. Jonas Karlman's kwiboo/rk3576 branch carried the upstream RK3576 U-Boot enablement, pinctrl, clocks, storage controller bindings, and has been merging into mainline through 2026. The rockchip-linux/rkbin tree had to ship a UFS-capable MiniLoader, which the RK3576MINIALL.ini recipe assembles from the DDR init, the UFS-aware loader, and the OP-TEE/ATF blobs. The Armbian side was the integration: a board config on U-Boot v2026.04, a U-Boot DT overlay that brings the UFS regulators and PHY up at the right moment, and a flashing path that upgrade_tool accepts. None of these were individually hard. Making them line up is what took the time. On the device, the stack does its job cleanly. The BootROM reads the IDB off UFS and pulls in the TPL; the TPL initialises DDR and the UFS host controller, sequences the regulators, negotiates the link, and reads the next stage; ATF jumps to U-Boot; U-Boot enumerates ufs 0 and loads the kernel; the kernel re-probes the same controller it just booted through. The work, almost all of it, lived at the TPL stage. Controller fine, PHY fine, but the device sits silent if regulator sequencing is wrong by a handful of milliseconds. Once that is right, the upper layers see a clean SCSI-shaped block device and the rest is unsurprising. What it leaves us withFor users with a UFS-equipped M5, the next release image flashes through the FriendlyElec Rockchip workflow with upgrade_tool, BOOT switch on UFS/SD, storage dropdown labelled "SATA". The board boots without an SD card or eMMC involvement, and armbian-install writes the same image to UFS in place once the system is running from another medium. Against microSD on the same hardware the difference is felt rather than benchmarked: small reads land faster, the system stays responsive under concurrent I/O, and the write endurance is in a different ballpark. A few rough edges remain. The vendor tooling will keep calling UFS "SATA" until either Rockchip relabels the GUI or rkdeveloptool grows a cs ufs opcode, neither on the immediate horizon. The BOOT switch is a hardware gate with no software override. And upgrade_tool ships only as a Linux x86_64 ELF, so flashing from an Apple Silicon Mac means a Linux VM with USB passthrough or a Windows host running the GUI. The same plumbing now unlocks every other UFS-equipped RK3576 board in the catalogue. The M5 reached the line first because the hardware was available and the upstream pieces were the most complete. The others should be substantially less work, now that the integration pattern exists and the loader path has been proven on real silicon. View the full article

Armbian's next release boots the FriendlyElec NanoPi M5 end-to-end from UFS on a mainline U-Boot, with no proprietary recovery image in the loop. It is the first RK3576 board in the catalogue to reach this state, and the integration pattern paves the way for the others. UFS, the storage class that replaced eMMC in phones, is packet-based and full-duplex with command queuing. The practical gain over an SD card shows up in random I/O, in latency under concurrent load, and in write endurance that holds up over years of deployment. FriendlyElec ships UFS on the M5 because the RK3576 has a native UFS controller, a sensible choice for any board destined for kiosks, robots, or industrial gateways. What mainline was missingThe UFS controller IP itself had a partial driver in mainline U-Boot. Everything around it was not wired: PHY init sequencing, the regulator rails the device needs before it responds, the device-tree glue that tells U-Boot "yes, this board has UFS." For the M5, none of it existed. There is also a cosmetic detail that catches every newcomer, namely that Rockchip's loader tooling labels UFS as SATA in the RKDevTool storage dropdown. Flashing goes through upgrade_tool, not the more familiar rkdeveloptool, because rkdeveloptool has never had UFS support. How it came togetherThree workstreams had to converge. Jonas Karlman's kwiboo/rk3576 branch carried the upstream RK3576 U-Boot enablement, pinctrl, clocks, storage controller bindings, and has been merging into mainline through 2026. The rockchip-linux/rkbin tree had to ship a UFS-capable MiniLoader, which the RK3576MINIALL.ini recipe assembles from the DDR init, the UFS-aware loader, and the OP-TEE/ATF blobs. The Armbian side was the integration: a board config on U-Boot v2026.04, a U-Boot DT overlay that brings the UFS regulators and PHY up at the right moment, and a flashing path that upgrade_tool accepts. None of these were individually hard. Making them line up is what took the time. On the device, the stack does its job cleanly. The BootROM reads the IDB off UFS and pulls in the TPL; the TPL initialises DDR and the UFS host controller, sequences the regulators, negotiates the link, and reads the next stage; ATF jumps to U-Boot; U-Boot enumerates ufs 0 and loads the kernel; the kernel re-probes the same controller it just booted through. The work, almost all of it, lived at the TPL stage. Controller fine, PHY fine, but the device sits silent if regulator sequencing is wrong by a handful of milliseconds. Once that is right, the upper layers see a clean SCSI-shaped block device and the rest is unsurprising. What it leaves us withFor users with a UFS-equipped M5, the next release image flashes through the FriendlyElec Rockchip workflow with upgrade_tool, BOOT switch on UFS/SD, storage dropdown labelled "SATA". The board boots without an SD card or eMMC involvement, and armbian-install writes the same image to UFS in place once the system is running from another medium. Against microSD on the same hardware the difference is felt rather than benchmarked: small reads land faster, the system stays responsive under concurrent I/O, and the write endurance is in a different ballpark. A few rough edges remain. The vendor tooling will keep calling UFS "SATA" until either Rockchip relabels the GUI or rkdeveloptool grows a cs ufs opcode, neither on the immediate horizon. The BOOT switch is a hardware gate with no software override. And upgrade_tool ships only as a Linux x86_64 ELF, so flashing from an Apple Silicon Mac means a Linux VM with USB passthrough or a Windows host running the GUI. The same plumbing now unlocks every other UFS-equipped RK3576 board in the catalogue. The M5 reached the line first because the hardware was available and the upstream pieces were the most complete. The others should be substantially less work, now that the integration pattern exists and the loader path has been proven on real silicon. View the full article

Hi @Marvin-03, could you try the latest build? It looks like your board is still using the BSP MMC driver, but we migrated to the mainline MMC driver last week. That should at least resolve the issue you're currently seeing. Also looking forward to your testing on the eMMC side, since the A7Z does not have eMMC support.

Board: Orangepi3-lts Images: * Armbian_26.5.1_Orangepi3-lts_trixie_current_6.18.33_minimal.img.xz Passed tests: * SHA-256 passed All below testing done via wired and wireless console connection(headless) * initial setup passed * create main user passed * update/upgrade check as root passed * log in as created user pass * update/upgrade check as the created user passed Result: All tested images do exist, are verified, and work properly

Hi @JamesCL. You cannot change the boot order of the SoC (SD -> eMMC -> MTD / SPI flash), thus i.e. the SD card is always booted if inserted. You can probably change the root file system's UUID, i.e. change the /boot/extlinux/extlinux.conf to give the kernel the command to use eMMC as root file system. HTH // Sven-Ola

Perhaps you can try to build Yamagi from source, as I pointed out, a developer has really optimized OpenGL ES. Here you can see it on a VisionFive 2, RISC-V SBC, hitting almost 200fps at 1080p! You can also try PS1 emulation with PCSXR (works without PS1 BIOS). I assume it's just: sudo apt install rpcsx .If you have a PS1 BIOS, you can also try Duckstation. If you need a game for testing, you can try Magic Castle. It was released for free. http://netyaroze.com/Media/Magic-Castle https://archive.org/details/magic-castle-2021-07-may Regarding eDuke32, did you try disabling compressed textures? https://wiki.eduke32.com/wiki/Frequently_Asked_Questions

I can confirm the 5GHz operation on DQ08 board. Now it's time to have a closer look at the kernel source and the non-matching DTS mess.

orangepi zero3 and 3w have, besides the confusing name, nothing in common. There is no support for any Allwinner A733 device in the framework yet. Best chance is to get in touch with Nick A since he tries to bring up support for raxda a7a, a7z, a7whateever devices which also use this SoC.

@Nick A Thanks for releasing the wonderful Armbian image for the Allwinner H618 and for supporting the community with your valuable suggestions. I recently purchased a TV box with 4GB of RAM and 64GB of storage running Android 12. I downloaded Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server.img.xz from here and flashed it to an SD card using BalenaEtcher. The box boots successfully, and I can configure it via the CLI. However, this motherboard is different from the ones previously posted here. The silkscreen on the board reads "X3Plus_H618_4bit_V3.0". Based on the naming convention and the appearance of the device, it seems to be the model available here. This board uses an FD6551 chip for the front VFD display. I have managed to extract .img file from the stock android. Are there any modifications I need to make to get the Wi-Fi, USB ports, and front VFD working? Could you please suggest? Things that are working: HDMI Display LAN Controller 1 out of the 2 USB ports. The port near to SD Card slot more precisely Things that are not working: WiFi - The chip got a metal shield. On top of the shield it is written with W804S1, inside the shield I could find AIC8800D40 chip. 1 x USB Port - Near the top left hand corner Front VFD display.

First of all, spamming balance on an SSD will significantly lower the lifespan of it. What you do is ask btrfs to relocate data-chunks that are occupying the % of a block, so that 1 goes fast is because they are very small (1%), but when you ask it to scan and look for a position to move chunks that occupy +50% it WILL take a long time, a veeeeery long time, not to mention 95%. You are basically just moving around data slowly killing your SSD. Read here: https://btrfs.readthedocs.io/en/latest/Balance.html#compact-under-used-chunks Btrfs will do this automatically in the background constantly when your computer is having extra cycles to do so. The only time it will be useful is if you remove massive amounts of data, then you can notice neither data nor metadata freeing up space. It can also be useful if you are using RAID because then it can move data between the disks. IIRC -susage is irrelevant for most users, what you want to move is the data and metadata, ie -musage & -dusage. If ever run a balance, it's when I remove big, and I mean BIG chunks of data, like 25% of the drive, and when I do, I start with 5, increment by 5 up to 35, NEVER more. But it is ONLY if I actually need the space immediately for something else, otherwise I just wait and let btrfs handle it by itself. So, with what you are doing with your cron running every day is literally killing your ssd... You should probably stop, IMMEDIATELY. With a --full-balance, you rewrite ALL DATA on the ENTIRE DRIVE! Better to have a scrub running once per month or every second week or so to know that your drive is in healthy condition... So what you are experiencing is not a bug, it's how it works, and in worst case scenario it might be your ssd about to give up... This link, albeit reddit describes it pretty good: https://www.reddit.com/r/btrfs/comments/hfpot9/what_does_balance_actually_balance BTW, you can check what it is doing while running by typing: sudo watch -n1 'btrfs balance status /path' But again, I HIGHLY discourage you do balance unless you ABSOLUTELY need to. Edit I missed that the filesystem has become read only when responding to this at 4am so lets edit this with a bit more info. Well, I'm sorry, it looks like you killed your drive, or at least the filesystem. The best you can do is try to copy all files on it to another drive (probably not worth trying to save the filesystem), format this one and pray that it's only your filesystem that became corrupt. But after reading how you treated that drive I think you should be prepared for it being damaged beyond a reformat, or that if you manage to format it, it will become corrupted pretty soon again, so I would not rely on that drive for backups... I have found SMART to not be reliable when it comes to health. If you like btrfs, I would recommend buying a rpi, a 6TB spinning drive, a hd case and run urbackup on that. That is what I use (rpi4 8gb, which is overkill, it never utilizes more than 2-3G memory on it, even though I use it as a backup server, nfs network drive AND is running a plex server on it) and it has been running flawlessly for years. (that reminds me, I might want to install something newer than rpi os bullseye on it, maybe armbian xD) I only make file backups, no images. Not very fast, but what does that matter when you only use it for backups. (I run the NFS network drive from another storage device, but that is beside the point) If you also use btrfs on the system you backup from, it creates a snapshot at runtime that it transfers files from, so there is no risk of corrupting files while the backup is running due to files changing during the backup. You would probably get all that for the same price as one ssd, or at least close to, spinning dives cost close to nothing. I have 5 clients connected to that backup solution, with 4 backups daily saved for about 2,5 months (one backup every 5hrs and backups paused between 3am-7am), and one archived every month to save for three years. ie 240 incremental backups per device. One of the clients backing up 1.13T (the others are smaller, between 100-350G each) but all of it only taking up about 5.5TB, and backups runs fast af, only copying changed data due btrfs and de-duplication (COW). I have NEVER had to run a balance on that device (only done it once before for testing). But since it is getting close to the threshold, let's make an experiment and run a balance on it with chunks up to 30%. There are 987 snapshots on that device (not all 5 clients has reached 240 backups due to not being constantly turned on, my laptop and my installed "fallback" os for example) $ sudo btrfs subvol list /media/backup | wc -l 987 This is before balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B The balance up to 20% took about 5 seconds, then on 25 and 30 it took a while, about 10 minutes (I forgot to run it with time so this is an estimate with me looking at the clock when starting and when saw it had it ended) It only moved a minimum amount of chunks $ sudo bin/btrfs-balance.sh --backup If balancing takes a long time, open another terminal and run: sudo watch -n1 'btrfs balance status /path' btrfs balance will run on /media/backup Do you want to continue? [y/n] y Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=5 SYSTEM (flags 0x2): balancing, usage=5 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=5 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=10 SYSTEM (flags 0x2): balancing, usage=10 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=10 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=15 SYSTEM (flags 0x2): balancing, usage=15 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=15 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=20 SYSTEM (flags 0x2): balancing, usage=20 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=20 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=25 SYSTEM (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks This is after balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B As you can see, no change whatsoever because btrfs does this in the background all by itself. And running higher % would not save any space, only take a ton of time, I'm pretty sure of that. If you want the script I used, here you go: (I have two btrfs filesystems on that rpi, modify to your liking if adopting) !/usr/bin/env bash # Check if script is run as root if [ "$EUID" != 0 ]; then echo 'THIS SCRIPT MUST BE RUN AS ROOT! (WITH SUDO)' exit 1 fi if [ "$1" == '--backup' ]; then METHOD='/media/backup' elif [ "$1" == '--usr' ]; then METHOD='/media/usr' else METHOD='all' fi echo 'If balancing takes a long time, open another terminal and run:' echo -e "sudo watch -n1 'btrfs balance status /path'\n" echo "btrfs balance will run on $METHOD" read -p "Do you want to continue? [y/n] " -n 1 -r if ! [[ "$REPLY" =~ ^[Yy]$ ]]; then echo '' echo 'Aborting...' exit 4 fi echo '' if [ "$METHOD" == '/media/usr' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/usr btrfs balance start -v -dusage=5 /media/usr btrfs balance start -v -musage=10 /media/usr btrfs balance start -v -dusage=10 /media/usr btrfs balance start -v -musage=15 /media/usr btrfs balance start -v -dusage=15 /media/usr btrfs balance start -v -musage=20 /media/usr btrfs balance start -v -dusage=20 /media/usr btrfs balance start -v -musage=25 /media/usr btrfs balance start -v -dusage=25 /media/usr btrfs balance start -v -musage=30 /media/usr btrfs balance start -v -dusage=30 /media/usr btrfs balance start -v -musage=35 /media/usr btrfs balance start -v -dusage=35 /media/usr fi if [ "$METHOD" == '/media/backup' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/backup btrfs balance start -v -dusage=5 /media/backup btrfs balance start -v -musage=10 /media/backup btrfs balance start -v -dusage=10 /media/backup btrfs balance start -v -musage=15 /media/backup btrfs balance start -v -dusage=15 /media/backup btrfs balance start -v -musage=20 /media/backup btrfs balance start -v -dusage=20 /media/backup btrfs balance start -v -musage=25 /media/backup btrfs balance start -v -dusage=25 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup fi exit 0 This probably means I should manually remove some snapshots, because I did make a few massive changes that caused a lot of new data to be created, I do NOT want it to become filled. Conclusion: Don't run btrfs balance unless absolutely necessary, especially on SSD:s!

I have the same problem, did anyone have this firmware?

This week's work centers on board support expansion, kernel and U-Boot maintenance, and desktop and CI tooling refinements. On the platform side, the Radxa Cubie A5E received Wi-Fi enablement and a kernel refresh as part of a broader update, while the youyeetoo YY3588 was promoted from CSC to standard support and the YY3568 gained PCIe NVMe functionality. The NanoPi R76S and Rock 5 ITX were both migrated to mainline U-Boot v2026.04, dropping vendor-branch gates, and the Vanxoak HD-RK3506-EVB was added with vendor and board imagery. Kernel hygiene dominated the maintenance work: duplicate OPP labels on the Xiaoxin Pad Pro (sm8250) were corrected, broken UHS-I, xo-clock, SD, and DSI patches were removed from sm8550 trees for both 6.18 and 7.0, and a now-upstream r-spi backport was dropped from sunxi-6.18. The odroidxu4-current branch advanced to 6.6.141 across two successive bumps. Desktop and infrastructure tooling saw layered improvements through configng: alsa-ucm-conf and libcamera/v4l userspace were added to the minimal tier, PackageKit and AppStream landed at the mid tier, and DE postinst scripts now execute in the build chroot to resolve missing wallpaper. UEFI x86 and arm64 desktop spins were switched to GNOME on the edge kernel, and build infrastructure gained inline ShellCheck PR feedback, scoped token permissions, fork-aware artifact gating, and event-driven runner cleanup via systemd hooks. #Armbian #EmbeddedLinux #Rockchip #UBoot #KernelDevelopment ChangesAdd vendor and board image of Vanxoak HD-RK3506-EVB. by @SeeleVolleri in armbian/armbian.github.io#316Add wifi to Radxa Cubie A5E (kernel7.0). by @juanesf in armbian/build#9879ci: post ShellCheck findings and auto-fix suggestions inline on PRs. by @iav in armbian/build#9868ci: scope GITHUB_TOKEN writes to job-level in maintenance-lint-scripts-post. by @iav in armbian/build#9887ci: skip build-artifacts gating job on forks. by @iav in armbian/build#9865desktops: install alsa-ucm-conf at minimal tier. by @igorpecovnik in armbian/configng#923desktops: install libcamera/v4l userspace at minimal tier. by @igorpecovnik in armbian/configng#924desktops: run DE postinst scripts in build chroot (fix missing wallpaper). by @igorpecovnik in armbian/configng#927enh: substring filter for the board picker. by @iav in armbian/build#9843expose: switch uefi-x86 / uefi-arm64 to GNOME desktop on edge kernel. by @igorpecovnik in armbian/armbian.github.io#315feat(ccache-remote): parse password from DNS-SD TXT for redis backend. by @iav in armbian/build#9864feat(tools/shellfmt): accept positional file args for scoped format. by @iav in armbian/build#9863fix(runners): handle missing HOME in systemd hooks for runner-clean-pages. by @igorpecovnik in armbian/configng#928fix(sm8250): drop duplicate cpu7_opp21 label on Xiaoxin Pad Pro overclock OPP. by @igorpecovnik in armbian/build#9882fix(sm8550-6.18): drop broken sm8x50 UHS-I/xo-clock mbox patch. by @igorpecovnik in armbian/build#9884fix(sm8550-7.0): drop merged & broken SD/DSI patches. by @igorpecovnik in armbian/build#9885fix(sunxi-6.18): drop r-spi backport now merged in linux-6.18.y stable. by @igorpecovnik in armbian/build#9883gha: don't double-quote board/maintainer filter values. by @iav in armbian/os#462gnome: add packagekit + plugins + appstream at mid tier. by @igorpecovnik in armbian/configng#922module_cockpit: drop qemu-kvm (no riscv64 build; qemu-system covers it). by @igorpecovnik in armbian/configng#926nanopi-r76s: bump mainline u-boot to v2026.04 and drop vendor-branch gates. by @SuperKali in armbian/build#9869release-targets: flip UEFI desktop spins from current to edge. by @igorpecovnik in armbian/armbian.github.io#314rock-5-itx: link upstream kernel commit in pcie3 refclk u-boot patch. by @SuperKali in armbian/build#9861rock-5-itx: switch to mainline u-boot v2026.04. by @SuperKali in armbian/build#9848Rockchip: youyeetoo yy3568: enable pci-e NVMe ssd. by @hqnicolas in armbian/build#9877runner-cleanup: event-driven _diag/pages wipe via systemd hooks. by @igorpecovnik in armbian/configng#925Update for Radxa Cubie A5E. by @juanesf in armbian/build#9626Update odroidxu4-current to 6.6.140. by @belegdol in armbian/build#9867Update odroidxu4-current to 6.6.141. by @belegdol in armbian/build#9881Update radxa-cubie-a5e.csc with current kernel for build. by @juanesf in armbian/build#9874youyeetoo-yy3588: promote from CSC to standard support. by @SuperKali in armbian/build#9873View the full article

This week's work centers on board support expansion, kernel and U-Boot maintenance, and desktop and CI tooling refinements. On the platform side, the Radxa Cubie A5E received Wi-Fi enablement and a kernel refresh as part of a broader update, while the youyeetoo YY3588 was promoted from CSC to standard support and the YY3568 gained PCIe NVMe functionality. The NanoPi R76S and Rock 5 ITX were both migrated to mainline U-Boot v2026.04, dropping vendor-branch gates, and the Vanxoak HD-RK3506-EVB was added with vendor and board imagery. Kernel hygiene dominated the maintenance work: duplicate OPP labels on the Xiaoxin Pad Pro (sm8250) were corrected, broken UHS-I, xo-clock, SD, and DSI patches were removed from sm8550 trees for both 6.18 and 7.0, and a now-upstream r-spi backport was dropped from sunxi-6.18. The odroidxu4-current branch advanced to 6.6.141 across two successive bumps. Desktop and infrastructure tooling saw layered improvements through configng: alsa-ucm-conf and libcamera/v4l userspace were added to the minimal tier, PackageKit and AppStream landed at the mid tier, and DE postinst scripts now execute in the build chroot to resolve missing wallpaper. UEFI x86 and arm64 desktop spins were switched to GNOME on the edge kernel, and build infrastructure gained inline ShellCheck PR feedback, scoped token permissions, fork-aware artifact gating, and event-driven runner cleanup via systemd hooks. #Armbian #EmbeddedLinux #Rockchip #UBoot #KernelDevelopment ChangesAdd vendor and board image of Vanxoak HD-RK3506-EVB. by @SeeleVolleri in armbian/armbian.github.io#316Add wifi to Radxa Cubie A5E (kernel7.0). by @juanesf in armbian/build#9879ci: post ShellCheck findings and auto-fix suggestions inline on PRs. by @iav in armbian/build#9868ci: scope GITHUB_TOKEN writes to job-level in maintenance-lint-scripts-post. by @iav in armbian/build#9887ci: skip build-artifacts gating job on forks. by @iav in armbian/build#9865desktops: install alsa-ucm-conf at minimal tier. by @igorpecovnik in armbian/configng#923desktops: install libcamera/v4l userspace at minimal tier. by @igorpecovnik in armbian/configng#924desktops: run DE postinst scripts in build chroot (fix missing wallpaper). by @igorpecovnik in armbian/configng#927enh: substring filter for the board picker. by @iav in armbian/build#9843expose: switch uefi-x86 / uefi-arm64 to GNOME desktop on edge kernel. by @igorpecovnik in armbian/armbian.github.io#315feat(ccache-remote): parse password from DNS-SD TXT for redis backend. by @iav in armbian/build#9864feat(tools/shellfmt): accept positional file args for scoped format. by @iav in armbian/build#9863fix(runners): handle missing HOME in systemd hooks for runner-clean-pages. by @igorpecovnik in armbian/configng#928fix(sm8250): drop duplicate cpu7_opp21 label on Xiaoxin Pad Pro overclock OPP. by @igorpecovnik in armbian/build#9882fix(sm8550-6.18): drop broken sm8x50 UHS-I/xo-clock mbox patch. by @igorpecovnik in armbian/build#9884fix(sm8550-7.0): drop merged & broken SD/DSI patches. by @igorpecovnik in armbian/build#9885fix(sunxi-6.18): drop r-spi backport now merged in linux-6.18.y stable. by @igorpecovnik in armbian/build#9883gha: don't double-quote board/maintainer filter values. by @iav in armbian/os#462gnome: add packagekit + plugins + appstream at mid tier. by @igorpecovnik in armbian/configng#922module_cockpit: drop qemu-kvm (no riscv64 build; qemu-system covers it). by @igorpecovnik in armbian/configng#926nanopi-r76s: bump mainline u-boot to v2026.04 and drop vendor-branch gates. by @SuperKali in armbian/build#9869release-targets: flip UEFI desktop spins from current to edge. by @igorpecovnik in armbian/armbian.github.io#314rock-5-itx: link upstream kernel commit in pcie3 refclk u-boot patch. by @SuperKali in armbian/build#9861rock-5-itx: switch to mainline u-boot v2026.04. by @SuperKali in armbian/build#9848Rockchip: youyeetoo yy3568: enable pci-e NVMe ssd. by @hqnicolas in armbian/build#9877runner-cleanup: event-driven _diag/pages wipe via systemd hooks. by @igorpecovnik in armbian/configng#925Update for Radxa Cubie A5E. by @juanesf in armbian/build#9626Update odroidxu4-current to 6.6.140. by @belegdol in armbian/build#9867Update odroidxu4-current to 6.6.141. by @belegdol in armbian/build#9881Update radxa-cubie-a5e.csc with current kernel for build. by @juanesf in armbian/build#9874youyeetoo-yy3588: promote from CSC to standard support. by @SuperKali in armbian/build#9873View the full article

https://github.com/armbian/configng/releases

@rosic shared it on MEGA, to flash use the instruction provided on my github. MEGA links: Rom - https://mega.nz/file/10wE1I6D#kMIPehB7qj5D9j6I1hw4aIUhGXMs7ZJsQgUnVFQfNEA Checksum - https://mega.nz/file/koh3HSJL#tbUEWwE-cNw1eo9HM4m15Qu0ax9D057HFTgoXd9wvmA

https://github.com/armbian/build/pull/9901

I think that the comment by @werner was mostly intended to set your expectations. Based on what you have said, you have a board that Armbian doesn't support at all. Second, you have found a similar board (Bpi M2 Ultra) that exists within Armbian. But that board is a csc board (Community Support). Which means it also isnt' supported by Armbian. But some developer in the community has as some point in the past contributed some work on it. Likely that developer no longer is around and that board doesn't get any meaningful maintenance. So you are doing the proper thing in using these forums to post your observation and question. But unless either you or some other volunteer in the community wants to work on this, it is unlikely to ever get much if any attention. That is the reality of a SBC world where the manufacturers don't support the software on their boards and the volunteers at Armbian can only work to support a few boards directly while providing the tools and framework for other community volunteers to add in partial support for some other boards.

Thank you

I know this is an old post, but I am desperate and saw you are using v 1.3.2. I have an Orange Pi 5 v 1.3.2 as well and I can't get it to boot. I have been trying a bunch of different OS's, Ubuntu and Ambian versions and it keeps failing. ChatGPT and Gemini both say it is a bad DBT file and then point me to the same version of Ambian to use. None of it seems to work, have you had any luck getting it to work? I haven't tried compiling the OS yet for it, I was hoping there was a stable version out there I could use.

New upstream BlueZ documentation helps simplify Bluetooth qualification for Linux-based products by mapping supported profiles, test requirements, software versions, and manual steps in one place. View the full article

It happened a few days ago that I rebuilt my complete firmware package to try something with another device. An HC4 firmware binary also automatically falls out in this process. If you like, you can put it on a microSD card (dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used}), place the prepared microSD card in your HC4 and start it with the boot button pressed. Check whether it meets your expectations, and if all tests are successful, you can transfer it to the SPI flash.

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