All Activity
- Past hour
-
@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.
- Today
-
I recently got an Orange Pi Zero 3W, and I noticed that the official Ubuntu image is still based on the sunxi BSP stack, using the sun60iw2-6.6.98 kernel, while the bootloader is also using an older version of U-Boot. Right now, I’m wondering whether it would be feasible to use AI agents to help compile an Armbian image for the Orange Pi Zero 3W with a mainline kernel, while still keeping the old vendor U-Boot for compatibility. Has anyone here experimented with a similar approach or have any good suggestions or ideas? I also really hope the official team can eventually provide a proper Armbian image for the Orange Pi Zero 3W, because I’ve run into quite a few issues with the stock official image.
-
Games Compatible With Armbian on Pinebook Pro
Katsujinken replied to Katsujinken's topic in Pinebook Pro
Oh I just downloaded Yamagi from Snap but OpenGLES was glitchy so I switched the settings to OpenGL 1.4 and it works great so I don't especially want to risk what might happen if I switch it to OpenGL 3.4 lol I also gave eduke32 a try and the flatpak version would launch Duke3D, Ion Fury, BloodCM, etc but have sound & no video despite what resolution I set it to or if it was on OpenGL vs Software. So I compiled the eduke32 mobile version which will launch my Duke Nukem 3D Plutonium Edition's duke3D.grp but give a CON file compilation error when I try those other build engine games. -
How you can help test upcoming Armbian 26.05 images?
Gabriel Becker replied to Igor's topic in Advanced users - Development
NanoPi M5 test report for 26.5.1 vendor images Board: NanoPi M5 Boot media: SD card Kernel branch tested: vendor 6.1.115 Test scope: quick first-boot / first-login / desktop smoke test only. I mainly tested the vendor kernel images because my intended use case requires vendor kernel support, especially for NPU-related use later. 1. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_gnome_desktop.img.xz` Result: OK What worked: * Booted from SD card successfully. * Armbian initial configuration completed successfully. * After initial configuration, the GNOME desktop started normally. * I was able to enter the desktop and open a few basic applications. Notes: * I did not do a full hardware validation in this round. * I did not collect serial logs because the image reached the desktop successfully. 2. Image: `Armbian_26.5.1_Nanopi-m5_resolute_vendor_6.1.115_kde-plasma_desktop.img.xz` Result: FAILED What worked: * Booted from SD card successfully. * Armbian initial configuration started normally. What did not work: * The system got stuck at the Armbian first-login / initialization screen when it was supposed to start the desktop. * It did not proceed to a usable KDE Plasma desktop. Notes: * I only did a basic desktop startup test. * I have not collected serial logs yet, but I can retest and provide logs if needed. 3. Image: `Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img.xz` Result: CLI OK, XFCE installation failed What worked: * Booted from SD card successfully. * Armbian initial configuration completed successfully. * Login to the terminal worked normally. * Basic CLI usage appeared normal. What did not work: * I tried installing XFCE through `armbian-config`, using the XFCE mid option. * The desktop package dependencies appeared to download successfully. * After that, the screen switched to a black screen with a blinking terminal cursor in the top-left corner. * I waited for about 10 minutes, but it stayed stuck there and did not continue to a usable desktop. Notes: * The base minimal image itself seemed to work correctly from the terminal. * The issue happened during or after the XFCE installation/startup process via `armbian-config`. * I have not collected detailed logs yet, but I can retest and provide logs if needed. Summary: * `resolute_vendor_6.1.115_gnome_desktop`: boots from SD card and reaches GNOME desktop successfully. * `resolute_vendor_6.1.115_kde-plasma_desktop`: boots from SD card, but gets stuck at the Armbian first-login / initialization screen and does not reach KDE Plasma. * `trixie_vendor_6.1.115_minimal`: boots from SD card and CLI works, but installing XFCE mid through `armbian-config` gets stuck on a black screen with a blinking cursor. -
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.
- Yesterday
-
I attempted to file a bug using `reportbug`, but since the kernel package is from Armbian and the report went to Debian, I assume that is a dead end. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1137721 I will mostly copy/paste from that report, here, but I also ran `armbianmonitor -u`. https://paste.armbian.com/wenegucita I run a home backup server with a 1TB SSD attached to an ODroid HC1 board. There is no redundancy, but I do keep a limited history of snapshots, taken hourly and trimmed down to a small number of hourly, daily, weekly, monthly, and yearly snapshots. There should be at most about 20 snapshots existing at a time. I have a daily cron job to run a balance operation. The mount point is `/backup` . Relevant line from /etc/fstab: /dev/mapper/backup /backup btrfs noatime,noauto,nodev,nosuid,noexec,compress=zlib:9 0 0 Command used for daily balance: btrfs balance start --full-balance '/backup' The filesystem only seems to be about half full: ansible@backup:~ $ sudo btrfs filesystem df --si /backup Data, single: total=430.57GB, used=428.24GB System, DUP: total=67.11MB, used=81.92kB Metadata, DUP: total=3.22GB, used=2.48GB GlobalReserve, single: total=536.87MB, used=49.15kB ansible@backup:~ $ My best understanding is that the messages that follow indicate that something is attempting to address space beyond 16TB, and that seems like a bug because my disk is only 1TB total. I would appreciate anyone with a firmer grasp of the topic at least confirming whether that is an accurate reading of the warnings and errors. If not, I might suggest that the warnings and errors could be improved, but I am open to correction if I just failed to understand what they are telling me. The problem seems to be triggered by any attempt to rebalance metadata or system data with a usage limit of 1 or higher. Excerpt from a command session: ansible@backup:~ $ time sudo btrfs balance start -musage=1 /backup; echo $? ERROR: error during balancing '/backup': Read-only file system There may be more info in syslog - try dmesg | tail real 0m0.304s user 0m0.040s sys 0m0.082s 1 ansible@backup:~ $ sudo umount /backup && sudo mount -o skip_balance /backup && sudo btrfs balance cancel /backup ansible@backup:~ $ time sudo btrfs balance start -f -susage=1 /backup; echo $? ERROR: error during balancing '/backup': Read-only file system There may be more info in syslog - try dmesg | tail real 0m0.321s user 0m0.023s sys 0m0.096s 1 ansible@backup:~ $ Excerpt from dmesg from that time: [114023.693265] BTRFS info (device dm-0): balance: start -musage=1 -susage=1 [114023.695656] BTRFS error (device dm-0): extent buffer 18905857064960 is beyond 32bit page cache limit [114023.695669] BTRFS error (device dm-0): reached 32bit limit for logical addresses [114023.695677] BTRFS error (device dm-0): due to page cache limit on 32bit systems, metadata beyond 16T can't be accessed [114023.695686] BTRFS error (device dm-0): please consider upgrading to 64bit kernel/hardware [114023.695699] ------------[ cut here ]------------ [114023.695706] WARNING: CPU: 4 PID: 30371 at fs/btrfs/space-info.h:208 btrfs_space_info_update_bytes_may_use+0x9c/0x1c0 [btrfs] [114023.695813] Modules linked in: aes_arm_bs crypto_simd dm_crypt cpufreq_conservative cpufreq_userspace cpufreq_powersave sunrpc zram zsmalloc binfmt_misc evdev sg nfnetlink ip_tables x_tables ipv6 autofs4 btrfs blake2b_generic xor xor_neon raid6_pq li bcrc32c sd_mod t10_pi crc64_rocksoft uas usb_storage scsi_mod scsi_common gpio_keys [114023.695959] CPU: 4 PID: 30371 Comm: btrfs Tainted: G W 6.6.122-current-odroidxu4 #1 [114023.695969] Hardware name: Samsung Exynos (Flattened Device Tree) [114023.695980] unwind_backtrace from show_stack+0x10/0x14 [114023.696000] show_stack from dump_stack_lvl+0x40/0x4c [114023.696014] dump_stack_lvl from __warn+0x78/0x154 [114023.696025] __warn from warn_slowpath_fmt+0x1b4/0x1bc [114023.696035] warn_slowpath_fmt from btrfs_space_info_update_bytes_may_use+0x9c/0x1c0 [btrfs] [114023.696127] btrfs_space_info_update_bytes_may_use [btrfs] from btrfs_block_rsv_release+0x1f4/0x2f4 [btrfs] [114023.696300] btrfs_block_rsv_release [btrfs] from btrfs_alloc_tree_block+0x118/0x6b4 [btrfs] [114023.696465] btrfs_alloc_tree_block [btrfs] from btrfs_force_cow_block+0x148/0xa60 [btrfs] [114023.696628] btrfs_force_cow_block [btrfs] from btrfs_cow_block+0xe4/0x2bc [btrfs] [114023.696792] btrfs_cow_block [btrfs] from btrfs_search_slot+0x6dc/0xc08 [btrfs] [114023.696957] btrfs_search_slot [btrfs] from btrfs_update_device+0xa4/0x248 [btrfs] [114023.697122] btrfs_update_device [btrfs] from btrfs_chunk_alloc_add_chunk_item+0xcc/0x638 [btrfs] [114023.697287] btrfs_chunk_alloc_add_chunk_item [btrfs] from reserve_chunk_space+0xec/0x180 [btrfs] [114023.697451] reserve_chunk_space [btrfs] from check_system_chunk+0x6c/0x74 [btrfs] [114023.697615] check_system_chunk [btrfs] from btrfs_inc_block_group_ro+0x228/0x234 [btrfs] [114023.697780] btrfs_inc_block_group_ro [btrfs] from btrfs_relocate_block_group+0x94/0x48c [btrfs] [114023.697945] btrfs_relocate_block_group [btrfs] from btrfs_relocate_chunk+0x3c/0x180 [btrfs] [114023.698108] btrfs_relocate_chunk [btrfs] from btrfs_balance+0x864/0x13b8 [btrfs] [114023.698272] btrfs_balance [btrfs] from btrfs_ioctl+0x248c/0x28c4 [btrfs] [114023.698436] btrfs_ioctl [btrfs] from sys_ioctl+0x288/0xc60 [114023.698533] sys_ioctl from ret_fast_syscall+0x0/0x54 [114023.698547] Exception stack(0xf2575fa8 to 0xf2575ff0) [114023.698556] 5fa0: 00000000 00000003 00000003 c4009420 bebe7fd0 bebe7f70 [114023.698565] 5fc0: 00000000 00000003 bebe7fd0 00000036 005bfb78 bebe86f4 00000001 0058b190 [114023.698572] 5fe0: 00000036 bebe7f58 b6d718b1 b6cdf736 [114023.698580] ---[ end trace 0000000000000000 ]--- [114023.698802] BTRFS error (device dm-0): extent buffer 18905857064960 is beyond 32bit page cache limit [114023.698821] ------------[ cut here ]------------ [114023.698827] WARNING: CPU: 4 PID: 30371 at fs/btrfs/block-group.c:2783 btrfs_create_pending_block_groups+0x674/0x67c [btrfs] [114023.698925] BTRFS: Transaction aborted (error -75) [114064.918054] Modules linked in: aes_arm_bs crypto_simd dm_crypt cpufreq_conservative cpufreq_userspace cpufreq_powersave sunrpc zram zsmalloc binfmt_misc evdev sg nfnetlink ip_tables x_tables ipv6 autofs4 btrfs blake2b_generic xor xor_neon raid6_pq libcrc32c sd_mod t10_pi crc64_rocksoft uas usb_storage scsi_mod scsi_common gpio_keys [114064.918234] CPU: 5 PID: 30410 Comm: btrfs Tainted: G W 6.6.122-current-odroidxu4 #1 [114064.918245] Hardware name: Samsung Exynos (Flattened Device Tree) [114064.918256] unwind_backtrace from show_stack+0x10/0x14 [114064.918272] show_stack from dump_stack_lvl+0x40/0x4c [114064.918284] dump_stack_lvl from __warn+0x78/0x154 [114064.918296] __warn from warn_slowpath_fmt+0x130/0x1bc [114064.918307] warn_slowpath_fmt from btrfs_create_pending_block_groups+0x674/0x67c [btrfs] [114064.918399] btrfs_create_pending_block_groups [btrfs] from __btrfs_end_transaction+0x38/0x2a0 [btrfs] [114064.918567] __btrfs_end_transaction [btrfs] from btrfs_inc_block_group_ro+0x1f0/0x234 [btrfs] [114064.918733] btrfs_inc_block_group_ro [btrfs] from btrfs_relocate_block_group+0x94/0x48c [btrfs] [114064.918899] btrfs_relocate_block_group [btrfs] from btrfs_relocate_chunk+0x3c/0x180 [btrfs] [114064.919065] btrfs_relocate_chunk [btrfs] from btrfs_balance+0x864/0x13b8 [btrfs] [114064.919231] btrfs_balance [btrfs] from btrfs_ioctl+0x248c/0x28c4 [btrfs] [114064.919397] btrfs_ioctl [btrfs] from sys_ioctl+0x288/0xc60 [114064.919491] sys_ioctl from ret_fast_syscall+0x0/0x54 [114064.919505] Exception stack(0xf26b9fa8 to 0xf26b9ff0) [114064.919516] 9fa0: 00000000 00000003 00000003 c4009420 beae9fc0 beae9f60 [114064.919527] 9fc0: 00000000 00000003 beae9fc0 00000036 0057fb78 beaea6f1 00000001 0054b190 [114064.919537] 9fe0: 00000036 beae9f48 b6d118b1 b6c7f736 [114064.919614] ---[ end trace 0000000000000000 ]--- [114064.919632] BTRFS: error (device dm-0: state A) in btrfs_create_pending_block_groups:2783: errno=-75 unknown [114064.919647] BTRFS info (device dm-0: state EA): forced readonly [114064.920025] ------------[ cut here ]------------ [114064.920039] WARNING: CPU: 5 PID: 30410 at fs/btrfs/space-info.h:208 btrfs_space_info_update_bytes_may_use+0x9c/0x1c0 [btrfs] [114064.920182] Modules linked in: aes_arm_bs crypto_simd dm_crypt cpufreq_conservative cpufreq_userspace cpufreq_powersave sunrpc zram zsmalloc binfmt_misc evdev sg nfnetlink ip_tables x_tables ipv6 autofs4 btrfs blake2b_generic xor xor_neon raid6_pq libcrc32c sd_mod t10_pi crc64_rocksoft uas usb_storage scsi_mod scsi_common gpio_keys [114064.920385] CPU: 5 PID: 30410 Comm: btrfs Tainted: G W 6.6.122-current-odroidxu4 #1 [114064.920398] Hardware name: Samsung Exynos (Flattened Device Tree) [114064.920409] unwind_backtrace from show_stack+0x10/0x14 [114064.920426] show_stack from dump_stack_lvl+0x40/0x4c [114064.920441] dump_stack_lvl from __warn+0x78/0x154 [114064.920454] __warn from warn_slowpath_fmt+0x1b4/0x1bc [114064.920466] warn_slowpath_fmt from btrfs_space_info_update_bytes_may_use+0x9c/0x1c0 [btrfs] [114064.920559] btrfs_space_info_update_bytes_may_use [btrfs] from btrfs_block_rsv_release+0x1f4/0x2f4 [btrfs] [114064.920729] btrfs_block_rsv_release [btrfs] from btrfs_trans_release_chunk_metadata+0x2c/0x40 [btrfs] [114064.920900] btrfs_trans_release_chunk_metadata [btrfs] from __btrfs_end_transaction+0x38/0x2a0 [btrfs] [114064.921070] __btrfs_end_transaction [btrfs] from btrfs_inc_block_group_ro+0x1f0/0x234 [btrfs] [114064.921239] btrfs_inc_block_group_ro [btrfs] from btrfs_relocate_block_group+0x94/0x48c [btrfs] [114064.921406] btrfs_relocate_block_group [btrfs] from btrfs_relocate_chunk+0x3c/0x180 [btrfs] [114064.921572] btrfs_relocate_chunk [btrfs] from btrfs_balance+0x864/0x13b8 [btrfs] [114064.921741] btrfs_balance [btrfs] from btrfs_ioctl+0x248c/0x28c4 [btrfs] [114064.921913] btrfs_ioctl [btrfs] from sys_ioctl+0x288/0xc60 [114064.922009] sys_ioctl from ret_fast_syscall+0x0/0x54 [114064.922024] Exception stack(0xf26b9fa8 to 0xf26b9ff0) [114064.922036] 9fa0: 00000000 00000003 00000003 c4009420 beae9fc0 beae9f60 [114064.922046] 9fc0: 00000000 00000003 beae9fc0 00000036 0057fb78 beaea6f1 00000001 0054b190 [114064.922057] 9fe0: 00000036 beae9f48 b6d118b1 b6c7f736 [114064.922067] ---[ end trace 0000000000000000 ]--- [114064.922111] BTRFS info (device dm-0: state EA): balance: ended with status: -30 I tried balancing data, starting with low usage limits and moving up to no limit. That all went smoothly. The problem still occurred when trying to balance metadata, but the extent buffer number named in dmesg errors changed. I do not know whether that is significant or whether balancing data should be expected to be of any benefit in this situation. I did not keep full context from dmesg, but these are the commands issued: btrfs balance start -dusage=1 /backup btrfs balance start -dusage=10 /backup btrfs balance start -dusage=50 /backup btrfs balance start -dusage=75 /backup btrfs balance start -dusage=85 /backup btrfs balance start -dusage=95 /backup btrfs balance start -d /backup Most of those were pretty fast. The last one took several hours. I also checked my SSD for SMART errors, running a short self test and then a long one. No errors are reported. I do not know whether this is an architecture specific bug. It may be specific to 32 bit systems, or to ARM 32 bit, or it may not. I do not know whether this is an upstream bug, but it seems likely. The behavior in question seems to be related to the btrfs kernel component. The recommended fix is to attach the SSD to a 64 bit system to complete any operations requiring addresses that cannot be handled by the 32 bit system. I have not done that, yet, and I will hold off for a while, as it seems like that will only be a temporary fix. If I can gather any more relevant information while the system is still in this state, please let me know. -- System Information: Debian Release: 13.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 6.6.122-current-odroidxu4 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
-
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
-
@Rodrigo Campos In my case the U-Boot side is not just a generic version choice. That baseline carries the board-specific path I tested: the zero2w-based defconfig, mmc0 broken-CD handling, H616 EMAC1/RMII support, I2C3 enablement, the LAN preinit step, and the extra EMAC-related clock/register writes. Since the kernel LAN attach depends on the board already being prepared by U-Boot, I preferred to keep the bootloader side conservative. So the short answer is: it is pinned because it is the validated baseline, not because I know of a hard conflict with every newer release.
-
Package armbian-config is not available
Werner replied to Dyfcom's topic in Software, Applications, Userspace
https://github.com/armbian/configng/releases -
Trying to boot Armbian on LinknLink iSG Box SE
Sancho replied to Sancho's topic in Rockchip CPU Boxes
@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 -
Package armbian-config is not available
Hannes replied to Dyfcom's topic in Software, Applications, Userspace
I have the same problem running a board with v26.2.1 for Rock 5B Plus running Armbian Linux 6.1.115-vendor-rk35xx Packages: Debian stable (trixie) that there is no install candidate named 'armbian-config'. I have two different systems running Armbian, one with "Debian (stable) Trixie" (which has the problem) and one with "Ubuntu stable (noble)" (same Kernel 6.1.115-vendor-rk35xx, same v26.2.1 dist) which has NO problem getting Armbian-Config package updated. After copying the apt-source from one to the other (Ubuntu -> Debian), it works fine. Was that intended? Here the code of the copied file '/etc/apt/sources.list.d/armbian.sources': Types: deb URIs: https://github.armbian.com/configng Suites: stable Components: main Signed-By: /usr/share/keyrings/armbian.gpg Looks like it works fine now ... Could you please confirm if I am doing okay with this? Thx in advance -
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.
-
https://github.com/armbian/build/tree/main/config/boards BOARD equals filename (without file extension) from above
-
Hello Thanks for you answer, I understand the point that if even though M2B & M2U are very close, it does not mean it will work. I really thought it was a simple thing to change "just" to turn off/on the board, as all the rest is perfect. I had a look to https://docs.armbian.com/Developer-Guide_Build-Preparation/ but honestly I am not skilled enough to to this, I did not understand how building it on my PC will make it work on the BananaPi, and the config ./compile.sh build \ BOARD=uefi-x86 \ #bananapim2b does not seem to exist BRANCH=current \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ KERNEL_CONFIGURE=no \ RELEASE=trixie does not help on which string using for my board. Regards
-
Using compile.sh for Orange Pi, PCIe/NVMe not working
teslik replied to ScottN's topic in Advanced users - Development
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. -
In the world of cheap ARM sbcs you cannot simply use image for board X and assume it works for board Y. It may up to a certain point, even boot, but you have to live with regressions. https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image If there is no pre-made image for a specific board, then you can DIY if it is even supported by the framework. keep in mind, boards in eos or csc status may or may not work. We don't know, we don't pay attention, we don't support.
-
Hello, Thanks for armbian on Banana PI, it is really wonderful compared to official releases. I installed the image "Armbian_community_26.2.0-trunk.904_Bananapim2ultra_trixie_current_6.18.29_minimal.img.xz" on my Banana PI M2 Berry (there is no image for this type), and all is working wonderfully well ... except rebooting or shutting down the Banana PI. When typing reboot, all services stop but the screen blocks on systemd-shutdown[1]: Rebooting. and it never reboots. It does the same for shutdown, stuck on same kind of message. Could you help me please ? Regards
-
**Board:** NanoPi M5 (RK3576) **Kernel:** 6.18.33-current-rockchip64 (#1 SMP PREEMPT Sat May 23 11:07:21 UTC 2026) **Armbian build:** v26.8.0-trunk.53 ## Problem Gigabit RX is completely non-functional on `end0` (GMAC0, `ethernet@2a220000`). The interface comes up at 1000Mb/s, TX works, but no packets are ever received. DHCP never gets an OFFER, `ethtool -S end0` shows RX counters stuck at zero. Forcing 100Mb/s via `ethtool -s end0 speed 100 duplex full autoneg off` works around the issue — RX starts working immediately. ## Root cause The DTB sets `phy-mode = "rgmii-id"` together with `rx_delay = <0x3f>`. The RTL8211F PHY in `-id` mode already applies its own internal RX delay, and the driver applies an additional hardware delay on top of it. The double delay breaks gigabit RX entirely. ``` # /boot/dtb/rockchip/rk3576-nanopi-m5.dtb — broken phy-mode = "rgmii-id"; tx_delay = <0x21>; rx_delay = <0x3f>; # <-- causes double RX delay ``` ## Fix Change `phy-mode` to `rgmii-rxid` (PHY applies RX delay internally) and remove `rx_delay`. This applies to both GMAC0 (`ethernet@2a220000`) and GMAC1 (`ethernet@2a230000`). ``` # Fixed phy-mode = "rgmii-rxid"; tx_delay = <0x21>; # rx_delay removed ``` After applying this fix gigabit works correctly at 1000Mb/s with full RX functionality. ## Workaround ```bash ethtool -s end0 speed 100 duplex full autoneg off ``` Or patch the DTB manually: ```bash dtc -I dtb -O dts -o /tmp/nanopi.dts /boot/dtb/rockchip/rk3576-nanopi-m5.dtb sed -i 's/phy-mode = "rgmii-id"/phy-mode = "rgmii-rxid"/g' /tmp/nanopi.dts sed -i '/rx_delay/d' /tmp/nanopi.dts dtc -I dts -O dtb -o /boot/dtb/rockchip/rk3576-nanopi-m5.dtb /tmp/nanopi.dts reboot ```
- Last week
-
Rupa X88 Pro 13 - RK3528 board with images
epost.deb replied to fedes_gl's topic in Rockchip CPU Boxes
Android DTB itself is broken in many ways, mainly because wifi gpios from DTB do not show up in the gpioinfo output. It is more important to put the brcm4335-sdio firmware in /lib/firmware/brcm, which is missing in the armbian repository. iw phy0 info shows support of the 5GHz channels, but i don't have such access points nearby. I will check tomorrow with my dual-band AP.
