All Activity

@iav Thank you . I've just tried your trixie build with the overlay applied in armbianEnv but unfortunately the kernel panics with another issue now DDR Version 1.25 20210517 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT U-Boot SPL 2026.04_armbian-2026.04-S88dc-Pc925-H6cef-Vfcb0-Bd0d2-R448a (May 08 2026 - 19:13:18 +0000) Trying to boot from MMC2 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK ## Checking hash(es) for Image atf-4 ... sha256+ OK load_simple_fit: Skip load 'atf-5': image size is 0! NOTICE: BL31: v2.13.0(release):armbian NOTICE: BL31: Built : 04:24:31, Mar 29 2026 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 287 INFO: plat_rockchip_pmu_init(1624): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x800000 INFO: SPSR = 0x3c9 ns16550_serial serial@ff1a0000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2026.04_armbian-2026.04-S88dc-Pc925-H6cef-Vfcb0-Bd0d2-R448a (May 08 2026 - 19:13:18 +0000) SoC: Rockchip rk3399 Reset cause: POR DRAM: 4 GiB (total 3.9 GiB) PMIC: RK808 Core: 359 devices, 33 uclasses, devicetree: separate SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... Reading from MMC(1)... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Kobol Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': Cannot persist EFI variables without system partition 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Loading Boot0000 'mmc 1' failed Loading Boot0001 'mmc 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'mmc@fe320000.bootdev': 1 script ready mmc 1 mmc@fe320000.bootdev.part /boot/boot.scr ** Booting bootflow 'mmc@fe320000.bootdev.part_1' with script Boot script loaded from mmc 1:1 170 bytes read in 2 ms (83 KiB/s) 24389419 bytes read in 1037 ms (22.4 MiB/s) 40503808 bytes read in 1712 ms (22.6 MiB/s) 90994 bytes read in 12 ms (7.2 MiB/s) Working FDT set to 12000000 485 bytes read in 11 ms (43 KiB/s) Applying kernel provided DT overlay rockchip-rk3399-helios64-cpu-stability.dtbo 2825 bytes read in 10 ms (275.4 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' ## Loading init Ramdisk from Legacy Image at 12180000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 24389355 Bytes = 23.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 12000000 Booting using the fdt blob at 0x12000000 Working FDT set to 12000000 Loading Ramdisk to f34bd000, end f4bff6eb ... OK Loading Device Tree to 00000000f4e12000, end 00000000f4e90fff ... OK Working FDT set to f4e12000 Starting kernel ... [ 2.690071] SError Interrupt on CPU4, code 0x00000000bf000002 -- SError [ 2.690098] CPU: 4 UID: 0 PID: 55 Comm: kworker/u26:1 Tainted: G M 6.18.30-current-rockchip64 #2 PREEMPT [ 2.690122] Tainted: [M]=MACHINE_CHECK [ 2.690128] Hardware name: Kobol Helios64 (DT) [ 2.690138] Workqueue: events_unbound deferred_probe_work_func [ 2.690176] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.690192] pc : rockchip_pcie_rd_conf+0x184/0x290 [ 2.690214] lr : rockchip_pcie_rd_conf+0x178/0x290 [ 2.690230] sp : ffff800080b537d0 [ 2.690236] x29: ffff800080b537d0 x28: ffffdb43365a3d68 x27: 0000000000000000 [ 2.690260] x26: 0000000000000001 x25: 0000000000000000 x24: ffffdb433672afb0 [ 2.690281] x23: 0000000000000000 x22: ffff800080b538a4 x21: ffff800080b53804 [ 2.690301] x20: 0000000000000000 x19: 0000000000000004 x18: 00000000ffffffff [ 2.690321] x17: 6572202c295d3030 x16: 2d3030207375625b x15: ffff800080b53670 [ 2.690340] x14: ffff000005fd9a1c x13: ffff000005fd9290 x12: dead000000000040 [ 2.690360] x11: ffffff800000007c x10: 0000000000000000 x9 : ffffdb43348c6288 [ 2.690380] x8 : 000000003d4d554e x7 : ffff000005717bc0 x6 : ffff000005718800 [ 2.690399] x5 : ffff000005719000 x4 : ffff800085000000 x3 : 0000000000c00008 [ 2.690419] x2 : 000000000080000a x1 : ffff800085c00008 x0 : ffff800085c0000c [ 2.690442] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.690451] CPU: 4 UID: 0 PID: 55 Comm: kworker/u26:1 Tainted: G M 6.18.30-current-rockchip64 #2 PREEMPT [ 2.690473] Tainted: [M]=MACHINE_CHECK [ 2.690478] Hardware name: Kobol Helios64 (DT) [ 2.690485] Workqueue: events_unbound deferred_probe_work_func [ 2.690509] Call trace: [ 2.690515] show_stack+0x20/0x38 (C) [ 2.690537] dump_stack_lvl+0x34/0x90 [ 2.690557] dump_stack+0x18/0x28 [ 2.690574] vpanic+0x328/0x378 [ 2.690592] panic+0x68/0x70 [ 2.690607] nmi_panic+0x74/0x80 [ 2.690622] arm64_serror_panic+0x78/0x90 [ 2.690642] do_serror+0x60/0xc0 [ 2.690659] el1h_64_error_handler+0x34/0x50 [ 2.690683] el1h_64_error+0x6c/0x70 [ 2.690699] rockchip_pcie_rd_conf+0x184/0x290 (P) [ 2.690718] pci_bus_read_config_dword+0x88/0xf8 [ 2.690737] pci_bus_generic_read_dev_vendor_id+0x38/0x1a0 [ 2.690760] pci_scan_single_device+0xb4/0x120 [ 2.690781] pci_scan_slot+0x74/0x218 [ 2.690800] pci_scan_child_bus_extend+0x50/0x2e0 [ 2.690821] pci_scan_bridge_extend+0x2c4/0x608 [ 2.690842] pci_scan_child_bus_extend+0x1c4/0x2e0 [ 2.690862] pci_scan_root_bus_bridge+0x6c/0xe8 [ 2.690883] pci_host_probe+0x38/0x118 [ 2.690904] rockchip_pcie_probe+0x548/0x678 [ 2.690921] platform_probe+0x64/0xa8 [ 2.690938] really_probe+0xc8/0x3a0 [ 2.690960] __driver_probe_device+0x8c/0x1b0 [ 2.690983] driver_probe_device+0x44/0x120 [ 2.691005] __device_attach_driver+0xc4/0x168 [ 2.691029] bus_for_each_drv+0x90/0xf8 [ 2.691050] __device_attach+0xa8/0x1c8 [ 2.691073] device_initial_probe+0x1c/0x30 [ 2.691098] bus_probe_device+0xb4/0xc0 [ 2.691122] deferred_probe_work_func+0xa4/0x100 [ 2.691151] process_one_work+0x174/0x3e8 [ 2.691182] worker_thread+0x194/0x328 [ 2.691204] kthread+0x14c/0x208 [ 2.691222] ret_from_fork+0x10/0x20 [ 2.691246] SMP: stopping secondary CPUs [ 2.691437] Kernel Offset: 0x5b42b4000000 from 0xffff800080000000 [ 2.691447] PHYS_OFFSET: 0x0 [ 2.691453] CPU features: 0x100000,04125800,40004001,0400421b [ 2.691466] Memory Limit: none [ 2.720107] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

I don't have a specific solution for you. I flashed my M1S just yesterday with the latest Minimal image and it worked just ootb. But what I recognized during tests of my self-compiled images was, that the M1S seems to be quite picky regarding the SD card and how it is flashed. My M1S showed a lot of different strange behaviors: very (I mean VERY!) slow boot, file system was read-only, no ethernet, kernel panics... I had to try different SD cards as well as different flashing tools to get it running. Interestingly the images that I flashed with Balena Etcher worked better than those flashed with the Armbian flasher. My No-HDMI-problem was solved by just using another cable... So maybe it is worth to try to just re-download the image and flash it with another tool to another SD card? Best whishes, Jojo

Thank you very much @Kevin su! Now my SBC HiBOX1644_V1.0 no longer needs a USB wifi. It was necessary to make some small modifications to work on kernel 6.6.44: https://github.com/Delutto/armbian_sv6256p/tree/Armbian_v24.11_Linux_6.6.44-current-sunxi64

@well0nez keep us updated on your progress.

sorry to answer this late. iam on vacation. iam owning an l018 and its in the bedroom too but i havent started on that one but things should be pretty similar. i am actually working on getting HDMI to work and requested GPL sources from allwinner.

Updating to include a few more I've successfully run... OpenMW - FOSS Engine to play Morrowind & it's KOTOR total conversion Starwind UFO: Alien Invasion - an XCom "homage" Yamagi Quake 2 - FOSS engine for Quake 2 Mods for Quake & Quake 2 probably work but I shouldn't squeeze any more games on the eMMC for now. If any of you can actually confirm that things like Slayer's Testaments, Brutalist Jam III, Slave Zero X Enyo, Prydon Gate, Dawn of Darkness etc work at a decent stable framerate then I'd appreciate it.

Hello good people. I honestly had given up on that thing, until last weekend, where I set my mind to finally get it to work. And work, it does! eMMC works, display output works without a trouble, and only today I've seen @eloirotava's comment about the 6051. And I'm calling for help again on that one. I currently am using the kernel 7.0.8-meson64 (the current edge for the tv box) and no matter what i'm doing, there's no way for me to get the correct linux-header files, to compile and install that module. May a kind soul help me? I'll post a full documentation very soon, and will probably push my work to the armbian git, once everything is clean. Thank you very much in advance!

I used Balena for the burning process, do I need another complementary program?

@Suly rtl8703bs works with 8723cs driver, but the proprietary driver has been disabled so far in newer kernels because maintenance was becoming more and more complex. Actually I don't remember if it works with the mainline kernel driver. Probably it works, but I don't know if it is enable in rockchip64 kernel; it is surely enabled in rockchip armhf family.

Howdy. if you have the tf uart adapter thingy, by the time it shows that on screen you are at the u-boot prompt where you can do what you want. e.g. start fastboot. I believe this tablet cannot be bricked because you can always enter FEL mode and use phoenixsuit. It can be maddeningly difficult to phoenixsuit to flash cold tablet but i recall it was like this: press and hold vol+ and power, plug usb cable with phoenixsuite ready to flash. release power button and vol+ few seconds later.

Problem remains the same. i have cloned a new build repos and patch with pr-9626 and rebuild image. console output result remains: U-Boot SPL 2026.01_armbian-2026.01-S127a-Pa547-Hc6a9-V2b7c-Bd0d2-R448a (May 18 2026 - 10:12:32 +0200) DRAM: 1024 MiB Something wrong with the uboot timing of the dram etc.? i can supplied the timing and trimming of the board with the funtional debian bootloader saved to spi. Setting of voltage regulators etc. see attached file. Regards Rolf hardcopy.0

Been doing some RK3588 board porting and kept running into the same category of bug — dtc compiles clean, dtbs_check passes, but the board either panics on suspend or a peripheral silently fails to probe. Stuff like: Peripheral on the EE supply wired to something that only stays alive in the AO domain → suspend-resume panic Copy-pasted a GPIO bank with 32 pins, used pin 35 → kernel panic at driver probe SPI clock request exceeds PLL maximum → silent bus hang Two nodes sharing the same GIC SPI interrupt line None of these are schema violations — they require knowing the actual cross-domain constraints of the SoC, which dtc has no idea about. So I wrote a Python tool that builds an in-memory model of the power tree, clock tree, and pin assignments, then runs constraint rules against it: $ pip install soc-consistency $ socc check board.dts --soc rk3588 error[PD-001] Power domain crossing — i2c@fe2b0000 uses vcc_3v3 (EE domain) but is connected to vcc_1v8 (AO domain). Will panic on suspend. error[GP-003] GPIO index out of bounds — gpio1 pin 35 on a 32-pin bank. warn[CK-003] Clock rate mismatch — spi0 requests 50 MHz from pll_cpll (max 24 MHz). There's also a decompile command that runs dtc on a binary blob and annotates the output with peripheral names from the SoC database — useful when you're staring at a vendor DTB and have no idea which block is at which address: $ socc decompile vendor.dtb --soc rk3588 gpio0@fd8a0000 /* GPIO0 (32-pin, 3.3V) */ { cru@fd7c0000 /* CRU — Clock and Reset Unit */ { RK3588 has the most complete constraint coverage right now. The constraint format is a simple YAML file — happy to accept PRs for other SoCs. GitHub: https://github.com/gahingwoo/SoC-Consistency Docs/rules reference: in the README If you hit false positives on a real BSP DTS, open an issue — BSP files from vendors tend to have a lot of "intentional" violations that I'm still tuning the rules around.

@Nick A TY very much for your reply, I've managed to create my first build but I am a bit confused because it made an IMG with a FAT32 boot partition, is it right or did I miss something?

try DIY image with this pr on top of main: https://github.com/armbian/build/pull/9626

After many weeks of research, testing and debugging I managed to put together an Unofficial Armbian Linux build for LinknLink iSG Box SE. Version: v26.05 Rolling Kernel: 6.1.115-vendor-rk35xx Flashed and booting from eMMC. All hardware working and tested, including Ethernet, WiFi and Bluetooth. Source, build and flashing instructions here https://github.com/luisdosreis/linknlink-isg-box-se-armbian If anyone is interested I can share a test image ready to be flashed or you can (and should) build it yourselves. I plan to add a Home Assistant flavor to the build system in the future.

Yes, the device is working now. Check the forum manjaro, they put kernel from sunxi and working now.

hello i have a new sbc board cubie a5e 1GB Ram starting via sdcard 32GB and tried to boot it with armbian cli image. Very early while the boards stuck with: RADXA Cubie A5E 1GB RAM Armbian CLI stuck while uboot via sdcard seems to be an issue with the uboot which hangs very early. With original debian image from radxa the board is b ooting and running. But i intend to use the armbian version with newer debian and kernel. What can i do? Regards Rolf

@jock Is it possible to dump BOOTROM from Linux, or is it hidden/shadowed by ATF ? There is RK3399 dumper code at github, so i am wondering if the same can be done on RK3528.

Note: This is for Odroid m1s, not Odroid m1 - there just isn't a forum for the m1s (yet?) When I tried to start the board with the community image for the Odroid m1s on a SD card, it wouldn't boot. The connected screen (HDMI) would stay black and the blue heartbeat LED would stay on permanently. I tried building and flashing u-boot but that didn't help me. Here's what DID work: (Note: it worked for me. I can't guarantee that this fixes it for everyone, use at your own risk) I mounted the SD card on a Linux desktop and created backups of the boot scripts (just to be safe) sudo cp <mount_path>/armbi_root/boot/boot.cmd <mount_path>/armbi_root/boot/boot.cmd.bak sudo cp <mount_path>/armbi_root/boot/boot.scr <mount_path>/armbi_root/boot/boot.scr.bak Then I set the load address to 0x0c000000 sudo sed -i 's/setenv load_addr "0x9000000"/setenv load_addr "0x0c000000"/' <mount_path>/armbi_root/boot/boot.cmd Then I ran mkimage as follows: sudo /usr/bin/mkimage -C none -A arm -T script -d <mount_path>/armbi_root/boot/boot.cmd <mount_path>/armbi_root/boot/boot.scr This fixed the booting, but just to be sure a future update wouldn't undo it I also wrote it to armbianEnv.txt echo "load_addr=0x0c000000" | sudo tee -a <mount_path>/armbi_root/boot/armbianEnv.txt And that's it! One more thing: I noticed that Ethernet did not work out of the box, so I did this: I attached a UART cable to log into the machine and created the following script, which patches the device tree. You might need to get a little creative if your only access would be through Ethernet, but you I'm sure you can figure something out. (Maybe create the necessary files while the SD card is still mounted on your PC) cat > /usr/local/sbin/patch-gmac-dtb.sh << 'EOF' #!/bin/bash DTB=/boot/dtb/rockchip/rk3566-odroid-m1s.dtb dtc -I dtb -O dts $DTB -o /tmp/m1s.dts 2>/dev/null # Only patch if not already applied if grep -q 'snps,reset-gpio' /tmp/m1s.dts; then echo "GMAC DTB patch already present, skipping" exit 0 fi sed -i '/phy-mode = "rgmii-id";/a \\t\tsnps,reset-gpio = <0x51 0x0f 0x01>;\n\t\tsnps,reset-active-low;\n\t\tsnps,reset-delays-us = <0x00 0x4e20 0x186a0>;' /tmp/m1s.dts sed -i '/reset-assert-us/d; /reset-deassert-us/d; /reset-gpios = <0x51/d' /tmp/m1s.dts dtc -I dts -O dtb /tmp/m1s.dts -o $DTB 2>/dev/null echo "GMAC DTB patch applied" EOF chmod +x /usr/local/sbin/patch-gmac-dtb.sh Execute the script and Ethernet should be working. (Might need a reboot, though). If this works, you should make sure this is applied after every kernel update, because it will get overwritten otherwise: # Run it automatically after kernel/dtb package updates cat > /etc/apt/apt.conf.d/99-patch-gmac-dtb << 'EOF' DPkg::Post-Invoke {"if [ -f /usr/local/sbin/patch-gmac-dtb.sh ]; then /usr/local/sbin/patch-gmac-dtb.sh; fi"}; EOF

Thank you! I ended up getting this working. For one, an update and reboot did get me the 6.18.10 kernel. Then, in the installation scripts for drivers, I just had to specify the package name for the headers explicitly, e.g. replacing: apt-get install linux-headers-$(uname -r) -y with apt-get install linux-headers-current-bcm2711 -y

I am using a Rock 5T 12GB board and have tested multiple Armbian images (24.04, 26.04, and others). Here is my experience so far: Armbian current images Audio does not work at all. When I plug in a 3.5 mm headset, nothing happens — no detection, no sound. Bluetooth works, Wi‑Fi does not. I have to manually compile the Realtek rtw89 wireless driver. After compiling, both Wi‑Fi and Bluetooth work, but still no audio output. Vendor (Radxa) images Audio works perfectly. When I plug in a headset, the system immediately detects it and asks whether it has a microphone. Sound output through the headset works as expected. However, with the vendor image I cannot use Bluetooth and Wi‑Fi at the same time. According to what I found online, the RTL8852BU chip shares internal resources. I must disable Wi‑Fi to use a Bluetooth mouse and keyboard reliably. Connecting a Bluetooth headset causes an immediate disconnect. Feedback from Radxa Radxa confirmed that the Bluetooth/Wi‑Fi coexistence issue is caused by the driver. Summary At the moment, I cannot use either the current Armbian images or the vendor images without running into major problems: Armbian: Wi‑Fi/Bluetooth OK (after manual driver build), but no audio. Vendor image: Audio OK, but Bluetooth and Wi‑Fi cannot work simultaneously. Is this a known issue, and am I the only one experiencing these problems? Thanks a lot for your support and help.

Hello everyone, I am reaching out to see if anyone in the community has successfully managed to get the internal Wi-Fi working on a box with the Realtek RTL8703bs chip. I have a MXQ Pro max (t9-RK3328) and I am using the latest Armbian build (Armbian_community_26.2.0-trunk.904_Rk3318-box_trixie_current_6.18.30_minimal.img.xz) provided by @jock for RK3318/RK3328 TV boxes. Here is the situation: 1. Using `rk3318-config` with `rk3318-box-led-conf1`, the chip is correctly powered and detected on the SDIO bus. 2. `dmesg` shows: `mmc1: new high speed SDIO card at address 0001`. 3. The hardware ID is confirmed as `024c:b703`. My questions : - Has anyone ever managed to make this specific chip (RTL8703bs) work on Armbian? - Does anyone have a patched driver (`.ko`), a specific `.dtbo` overlay, or a workaround that doesn't require recompiling the entire kernel from scratch? Here is my system log for reference: https://paste.armbian.com/ecadekazaz Thank you very much for your time and any advice you can share!

The one from my firmware build.

Solved it by simply removing the upstream folder which had some symlink tomfolery 1. rm -rf /lib/firmware/qcom/sm8550/ayn/ 2. apt update && apt upgrade 3. PROFIT <3

What U-Boot/bootloader is in the MTD?