Active threads

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

I'll check tonight which revision i have.

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.

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.

I recognize this is an old thread - but there are no newer ones open and I figure having one thread instead of many is best. I'm trying to do the same thing as you OP, getting a raspberry pi DSI display working on a rockpi 4b+. I tried to adapt Radxa's DTS in a similar way you did from Armbian's Base DTS, and seeing what definitions changed and I came up with this non working DTS: Which gives the following DMESG error, very similar to yours: `[ 21.477004] rpi-ts-dsi ff960000.dsi.0: failed to attach dsi to host: -517 [ 21.477086] mipi-dsi ff960000.dsi.0: deferred probe pending: (reason unknown)` You'll note various differences between our DTS, like panel_in instead of panel_in_dsi, and mipi_dsi instead of mipi_dsi1. I based these off looking at the base DTS in Armbian kernel 6.18.32, but also on this project I found recently that brings support for 7 and 10 inch Osoyoo brand of DSI panels to the RockPi 4b+. I think that's really promising and will help with bringing DTS support to the raspberry pi panel (and others that are compatible). I recommend you look into it. I will continue iterating and update this thread with results if any. I don't think OP was pinning the problem on Armbian. OP was asking how to configure a custom DTS to work with the hardware they have. This is the community support forum, which is the correct place for this kind of discussion.