All Activity

@maxsub: I have not really analyzed Armbian build caching until now. Maybe a previous build for another spacemit board prevents the DKMS from being included? Anyhow, re-installing / updating a kernel image should trigger any active DKMS modules to rebuild for the new kernel on the board, so this looks correct. LG // Sven-Ola

The bcmdhd dkms is getting built and the debs are being updated if I use SKIP_ARMBIAN_REPO=yes. [🐳|🔨] Building for 6.18.9-edge-spacemit [🐳|🔨] [🐳|🔨] Building initial module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for 6.18.9-edge-spacemit [🐳|🔨] The kernel is built without module signing facility, modules won't be signed [🐳|🔨] [🐳|🔨] Building module(s)............................... done. [🐳|🔨] Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz [🐳|🔨] Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz [🐳|🔨] Running depmod.... done. [🐳|🔨] Processing triggers for man-db (2.13.1-1) ... When installing the image deb the previous dkms gets deleted. Preparing to unpack linux-image-edge-spacemit_26.02.0-trunk_riscv64__6.18.9-S3aec-D0000-P87b2-C50afHfe35-HK01ba-Vc222-B052a-R448a.deb ... Armbian 'linux-image-edge-spacemit' for '6.18.9-edge-spacemit': 'prerm' starting. dkms: removing module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64) Module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64): Before uninstall, this module version was ACTIVE on this kernel. Deleting /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz Deleting /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz ......... It gets built during install of the image deb: Autoinstall of module bcmdhd-spacemit-sdio/101.10.591.84.37-4 for kernel 6.18.9-edge-spacemit (riscv64) Building module(s).............................................. Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/bcmdhd.ko.xz Installing /lib/modules/6.18.9-edge-spacemit/updates/dkms/dhd_static_buf.ko.xz Running depmod.....

@marcosdsdba Can you take a picture or just tell us the Wi-Fi chip you have on your board?

@Rodrigo Campos The 20251226 build uses a newer kernel, but audio through the A/V out port is currently broken. I haven't had time to fix it yet, so if you don't need that port, feel free to use this version.

If you can pull the factory DTB from that board that would be great. I need it to get Wifi working

Hi dear @Nick A, I need your help to understand the branch to use in your repository, the main one is 20250306, but there are several branches that looks like more recent, like 20251226. May you explains what is more recent/better to use for an Transpeed M98?

I buy a different USB uart Usbuart Maybe I can do what you suggest. I need to wait to the item arrives at my home. When It arrives I post here to the device read uart method.

@sven-ola The dkms did not get installed by the build. I manually installed it and the wifi works. I am trying the build with SKIP_ARMBIAN_REPO now as I did not have that before.

I am trying to setup Raxda Display 8 HD with Radxa ROCK 3A. On official Radxa OS, I used Rsetup tool to setup overlay for `Radxa Display 8 HD' using official guide. How can I do same on Dedicated applications images with Armbian Linux v6.12 ( Home Assistant ) ? I have read Device Tree overlays guide on armbian docs but I can't find overlay for lcd display in files:

Thank you! That worked like a charm

@Robin Hoo I don't have UFS so I can't test it. But I think if you add enable_extension "ufs" to https://raw.githubusercontent.com/NickAlilovic/build/refs/heads/Radxa-A7A/config/boards/radxa-cubie-a7a.csc it might work. git clone https://github.com/NickAlilovic/build.git --branch Radxa-A7A cd build echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7a.csc or echo 'enable_extension "ufs" ' >> config/boards/radxa-cubie-a7z.csc ./compile.sh

Tried this? https://gist.github.com/c0m4r/b3fea6342bcf5a1b25b608fc36100d68#pwm-fan-control Ie: download the script and systemd service, edit the script to your liking (or try default) and activate the service. As default It configures to user_space and checks temps every 10s. https://raw.githubusercontent.com/c0m4r/radxa_rock5c_lite/refs/heads/main/usr/local/bin/rock5c_fan_pwm ########################################################## # Radxa Rock 5C fan PWM control script # Author: https:///github.com/c0m4r # License: Public Domain ########################################################## # PWM control path PWM_PATH="/sys/devices/platform/pwm-fan/hwmon" # Configuration INTERVAL=10 # Temperature check interval (seconds) FAN_OFF=1 # 1 = turn off fan below MIN_TEMP after cooldown, 0 = keep at min RPM COOLDOWN=300 # time to wait before turning off the fan when FAN_OFF=1 # Critical temp protection POWEROFF_ON_CRIT=1 # 1 = shutdown when the temperature reaches a critical value, 0 = disable CRITICAL_TEMP=70 # Critical temperature (shutdown) # PWM Values (proper) SAFE_PWM_MIN=105 # Safe minimum PWM to keep fan spinning PWM_LOW=125 # 45–50°C (~50% speed) PWM_MID=165 # 50–55°C (~65% speed) PWM_HIGH=200 # 55–60°C (~80% speed) PWM_MAX=255 # >60°C (100% speed) # PWM Values (temporary - use these instead of proper if the fan spins at max all the time) #SAFE_PWM_MIN=50 # Safe minimum PWM to keep fan spinning #PWM_LOW=60 # 45–50°C (~50% speed) #PWM_MID=70 # 50–55°C (~65% speed) #PWM_HIGH=80 # 55–60°C (~80% speed) #PWM_MAX=255 # >60°C (100% speed) # Constants (requires also changes in code) MIN_TEMP=47 # Minimum temperature (PWM_MIN) MAX_TEMP=60 # Maximum temperature (PWM_MAX) # Set thermal policy thermal_zones=$(ls -1 /sys/class/thermal | grep thermal_zone) if [[ "$thermal_zones" ]]; then for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done else echo "No sensors found, check kernel support, setting fan to high for now!" echo $PWM_HIGH > ${PWM_PATH}/hwmon*/pwm1 exit 1 fi # Set PWM_MIN based on FAN_OFF mode if [ "$FAN_OFF" -eq 1 ]; then PWM_MIN=0 # Allow fan to turn off after cooldown else PWM_MIN=$SAFE_PWM_MIN # Keep fan at minimal safe RPM all the time fi # Validate PWM path if [ ! -d "$PWM_PATH" ]; then echo "Error: PWM control file not found: $PWM_PATH" exit 1 fi # Initialize variables current_pwm=$(cat ${PWM_PATH}/hwmon*/pwm1) # Start at current PWM last_high_temp_time=0 # Track last high temp for cooldown echo "Initializing fan at PWM $current_pwm" echo "$current_pwm" > ${PWM_PATH}/hwmon*/pwm1 # Main loop while true; do for i in /sys/class/thermal/thermal_zone*/policy ; do echo "user_space" > "$i" done <snip>

Thanks for the feedback , i have finally downloaded this version and burn into sd card , put in sd card then reconnect power, the system normal boot i cant see armbian screen, the blue light is on, and nothing on screen or dark screen can someone point me please what is happening.

The drm_prime error is somehow "normal": AFAIR mpv was trying each hardware decoder in turn and, if it does not support the codec, prints the error and tries the next hardware decoder in line. If you try to decode h.265, perhaps it first picks an hardware decoder which does not support such codec with such parameters and prints the error, then tries another decoder which is capable and everything works. Usually rockchip devices have two hardware decoders, Hantro and rkvdec; Hantro does not support h.265 at all on older chips, but rkvdec does.

@ArturHey you did a lot of experimentation, but actually I think you are stuck on something different. GPT partition error message is something you can totally ignore, either because stock firmware usually don't provide a GPT partition, and armbian images neither do. The rockchip miniloader supports GPT partition table, but it is not mandatory to work. If there's a GPT partition, the miniloader searches for "uboot" and "trust" partitions to use them as hints for the base addresses. If there's no GPT partition, it will just use default base addresses and look for the LOADER and TRUST signatures. Anyway, armbian does not use anything from that: there is no rockchip miniloader, neither are GPT partitions or other proprietary code, except for the Trust OS, which is embedded into u-boot. The boot process is totally different on armbian. Now, the issue you have with flash not being recognized by rkdeveloptool makes me think about three possibile situations: a bug in rkdeveloptool you are still in maskrom mode and did not upload the usbplug firmware with rkdeveloptool db (ie: the board is not yet initialized) a broken flash in the eMCP part You can, for example, refer to the procedure Installation (without SD card, board with eMMC) described in the first post of this thread if you want to write a raw image in the flash memory but I always suggest to erase the flash memory and test the image via sdcard first, rather than installing the image immediately, because you can softbrick the board. About the non-booting multitool, you should post some logs from the serial uart, but probably the main issue is related to the trust os which freezes the board after few seconds.

I now found a workaround, basically adding the following to the top of /boot/boot.cmd setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" and running mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr (as shown at the bottom of /boot/boot.cmd However this is not sustainable, and it would still be preferable if the inclusion of armbianEnv.txt could be fixed, ESPECIALLY considering that the download page https://www.armbian.com/odroid-n2/ gives the following (useless due to this issue) advise: On modern kernels adding “video=HDMI-A-1:1920x1080M@60D” to boot /boot/armbianEnv.txt (extraargs=) should force HDMI to 1080p instead of the 4K native resolution.

Probably because nobody had use for those until today. Feel free to send a PR adding whats missing.

https://www.armbian.com/download/ https://github.com/armbian/os/releases https://github.com/armbian/community/releases

Hey, Where can I find the latest images for the Odroid HC1 and ZeroPi? https://www.armbian.com/odroid-xu4/ https://www.armbian.com/zero-pi/ I understand that both SBCs are quite old and probably long forgotten by Armbian users, but I need a clean install on both and am looking for the latest existing images. I tried looking at https://armbian.lv.auroradev.org/archive, but it seems not everything is there. Thanks in advance for any help. PS Anyone still using these SBCs? Are there any alternatives in 2026 at reasonable prices?

Thanks @Sanjay, are you running Trixie? I was trying new driver (r8152) the other days as well, I tried your approach on a fresh install and still having the same issue (I can write to an OMV share with around 220MB, but reading back crashes the 2.5 interface); as far as I read some additional network & power management settings are needed, just didn’t find the right combination so far. Out of curiosity I dusted off the old SD card that still had my initial setup on buster, booted from it and on the same tests I get around 180MB write and 220MB read without any crash. Will spend some more time on it and if not I’ll just leave it as is, I can use the 1g network with no issue, the nas will not be running 24x7 anyway, it’s just for some backups every now and then. Just that my OCD wants the 2.5 interface to be there as well.

@ArturHey Try flashing the TrustOS at 0x2000 since that's where your board is looking for TOS, then flash U-Boot at 0x4000. Basically swapping them out. if anything different happens, let us know.

why edge kernels missing the dvb modules?

Compiled, flashed, uploaded. I got a running XFCE desktop and a working wifi applet. If you still have different results, I may provide a VPN endpoint and an SSH pubkey to log in to your machine. Here's my upload dir: HTH // Sven-Ola

[UPDATE] Manual Partition Strategy on RK322x (Kingston eMCP) - GPT Signature Error & TOS Anomaly Hi everyone, Following up on my struggle with the "Red LED" issue on this RK3228A box (Kingston eMCP). Since the Multitool wouldn't boot from the SD, I moved to a more aggressive approach using rkdeveloptool on macOS to flash Armbian images and the Multitool components directly to the internal storage. The Loader Struggle (Samsung vs. Kingston) I compiled rkdeveloptool on macOS and tested multiple loaders to initialize the RAM/Flash: • rk322x_loader_v1.10.256.bin • rk322x_loader_v1.11.253.bin • rk322x_loader_v1.10.238_256.bin None of them solved the SD boot issue. Interestingly, they identify my flash as SAMSUNG, even though the physical chip is Kingston: Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 7216 MB | Block Size: 512 KB | Page Size: 2 KB Tested Images & Offsets (Direct Flashing via rkdeveloptool) • Armbian Community (6.1.62/Minimal 6.18.7): Tested 0x0 and 0x8000. • LibreELEC (10.0, 11 and 12): Tested 0x0 and 0x8000. • Multitool (v1.11 & Standard): Tested 0x0 and 0x2000. • Educabox (Legacy 4.4.194 / NAND): Tested 0x0. All attempts resulted in "GPT signature wrong", likely because the Secure Boot/Trust OS expects the Android rkparameter structure instead of a standard GPT. When I then changed the GPT table in parameters.txt, it sometimes wouldn't even give me a signal via serial. The Strategy: Manual Image Construction (Partition Replacement) Since full image flashing failed, I followed the "Partition Replacement" strategy to manually construct the layout. I read about it in a post titled long story LINUX on rk3229 rockchip by @fabiobassa: manually constructing the partition layout to satisfy the Bootrom's legacy requirements while injecting Armbian components into specific offsets. The parameter.txt Modification (The Key Step): The root cause of the "GPT signature wrong" error was the mismatch between the Android partition table expected by the device's Secure Boot/Trust OS and the standard GPT layout of Linux images. Original State: The stock parameter.txt defined over 12 Android-specific partitions (cache, recovery, kpanic, metadata, etc.), complicating the boot process. Modified State: I manually edited parameter.txt to consolidate all user partitions into a simplified Linux layout. I removed the Android clutter and defined a single large system partition for the RootFS. New Layout Definition: mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00004000@0x00004000(trust),0x00007800@0x0000A800(resource),0x00006000@0x00012000(kernel),0x00006000@0x00018000(boot),-@0x00028000(system) Component Preparation (Where the files came from) I did not use generic loaders for the boot partition. Instead, I extracted and repackaged each component on macOS to fit this new map: U-Boot (uboot @ 0x2000): I extracted the original bootloader from my device backup using dd to preserve compatibility. Command: dd if=backup_original.img of=uboot_extraido.img skip=8192 count=8192 System/RootFS (system @ 0x28000): I extracted the raw EXT4 Linux partition from the Armbian image. Command: dd if=Armbian...minimal.img of=particao_linux.ext4 skip=8192 count=2269184 Kernel (kernel @ 0x12000): Extracted vmlinuz-6.18.7-rockchip from the Armbian image and wrapped it with Rockchip headers using mkimage. Command: mkimage -A arm -O linux -T kernel -C none -a 0x60408000 -e 0x60408000 -n "Linux" -d vmlinuz... kernel.img Ramdisk (boot @ 0x18000): Extracted uInitrd from Armbian and wrapped it as a ramdisk image. Command: mkimage -A arm -O linux -T ramdisk ... -d uInitrd... boot.img Resource/DTB (resource @ 0xA800): I used the specific Device Tree Blob for this box (rk322x-box.dtb) extracted from the Armbian build and renamed it to resource.img. Afterwards, I tested with resource-linux which was linked in the original discussion, but still did not have success. The Flashing Sequence & Current Anomaly With the files prepared and the partition map redefined, I flashed the components using rkdeveloptool. The Sequence: Initialize: db rk322x_loader_v1.10.238_256.bin Partition Map: prm parameter.txt (Injecting the simplified layout). Flash Images: wl 0x2000 uboot_extraido.img (My extracted U-Boot) wl 0x4000 trust_with_ta_ga4fd2d1.img wl 0xA800 resources-linux.img (The DTB) wl 0x12000 kernel.img wl 0x18000 boot.img wl 0x28000 particao_linux.ext4 (The Armbian RootFS) The Result (The "TOS" Anomaly): The write process returns 100% Success, but the device fails to boot. The serial log (1.5Mbps) reveals a loop with a specific error: GPT 0x63337df8 signature is wrong recovery gpt fail! tag:LOADER error,addr:0x2000 hdr 633377e0 + 0x0:0x20534f54,0x20202020... The Anomaly: The error points to address 0x2000. The header read back is 0x20534f54, which is ASCII for "TOS " (Trust OS). It seems the Bootrom or the initial loader is hardcoded to expect the Trust Image at 0x2000, but my parameter.txt (and the standard Rockchip layout) places U-Boot at 0x2000 and Trust at 0x4000. Even when I flash my extracted U-Boot there, the system seems to be looking for a Trust signature. At this point, I don't know what I'm doing anymore and have spent around 20 hours in this project testing things. Any guidance on how to proceed from more experienced devs such as @fabiobassa, @Harleyyyu and @jock would be greatly appreciated to save my sleepless nights. Thanks for reading.

Hello @Malay! Same for you: cannot reproduce. Can you rebuild with SKIP_ARMBIAN_REPO=yes? This builds a little longer but skips cached stuff. Alternatively, rm -r ./cache from the build dir. To help with this, I will start the following commands on my PC and upload the results later to https://privat-in.de/ (Download section). LG // Sven-Ola