All Activity

Patched the .dtb for v6.1, currently not yet in final format. I will probably create a commit to Armbian with a .dts for our board. I am attaching the dtb/dts just to keep track of the progress. Here are results of the RKNN test launch: rknn_api/rknnrt version: 2.3.2 (429f97ae6b@2025-04-09T09:09:27), driver version: 0.9.8 model input num: 1, output num: 1 input tensors: index=0, name=input, n_dims=4, dims=[1, 224, 224, 3], n_elems=150528, size=150528, fmt=NHWC, type=INT8, qnt_type=AFFINE, zp=0, scale=0.007812 output tensors: index=0, name=MobilenetV1/Predictions/Reshape_1, n_dims=2, dims=[1, 1001, 0, 0], n_elems=1001, size=2002, fmt=UNDEFINED, type=FP16, qnt_type=AFFINE, zp=0, scale=1.000000 custom string: Begin perf ... 0: Elapse Time = 8.06ms, FPS = 124.12 ---- Top5 ---- 0.935059 - 156 0.057037 - 155 0.003881 - 205 0.003119 - 284 0.000172 - 285 So: CPU: OK GPU: OK via Panfrost NPU: OK, RKNN inference works on RKNPU rk3566-box-X88PRO20-npu.dtb rk3566-box-X88PRO20-npu.dts

Can you give more details about the limitations of this NPU? I thought that they would be using shared system RAM. because all models are multiple megabytes, Can you comment about the ability to convert any model to your desired NPU target with "AI model conversion" https://tinycomputers.io/posts/rockchip-rk3588-npu-benchmarks.html (search for "Conversion Performance (x86_64)") Maybe its possible to run LCM-Lora in an armbian device, if it has 16GB. It is already running in a 16GB laptop without NPU or GPU. https://forums.raspberrypi.com/viewtopic.php?t=398225&sid=2b66e2cebe37506dd74215ead3dd264c I am thinking about buying an Orange PI zero 3W (allwinner NPU), but if you have troubles with a 6 TOPs NPU, I will have more troubles with a 2 TOPs NPU

Refer to the experiences here: I think someone wrote that the mainline kernel has NPU support. Is this NPU going to load only models that are in the Rockchip model repository?

This week's updates center on new board enablement, Rockchip platform refinements, and tooling and kernel maintenance. Board support expanded across multiple silicon families, with the addition of Seeed Studio reComputer RK3576/RK3588 DevKits and the Anbernic RG DS handheld image. The EasePi A2/R2 received substantial revisions to its board configurations and device trees, alongside a vendor logo transition to Linkease. SpacemiT K1 boot support was updated, and per-SoC LINUXCONFIG separation was introduced for the TQ family to better isolate kernel configurations. Rockchip received the bulk of low-level improvements. Notable changes include AUX recovery for USB-C DP Alt Mode in the dw-dp driver, device-tree-based LED configuration for the r8169/r8125 controllers, and an updated patch ensuring stable PCIe Ethernet MAC addresses across many boards. Additional fixes resolve slow WiFi on the NanoPi R76S via SDIO SDR104, enable Bluetooth on the Orange Pi 5 Ultra edge kernel, and restore the tm16xx driver on current kernels. On the tooling and maintenance side, Armbian Imager 2.0 was released, the mainline kernel was bumped to 7.1-rc6, and the rtl8192eu driver was re-enabled following a cleanup of compilation warnings. A previously merged USB gadget NULL pointer fix was reverted pending further evaluation. #Armbian #EmbeddedLinux #Rockchip #SBC #KernelDevelopment Changesmainline: bump to 7.1-rc6. by @EvilOlaf in armbian/build#9922Add Anbernic RG DS board image and Anbernic vendor logo. by @crackerjacques in armbian/armbian.github.io#326Add jellyfin-ffmpeg release constraints and ip-wrapper for easepi-r2. by @ifroncy01 in armbian/build#9942arm64: dts: overlay: add radxa display 8hd for rock5t. by @Ken-Vamrs in armbian/linux-rockchip#498board-vendor-logos: update EasePi vendor logo to Linkease. by @ifroncy01 in armbian/armbian.github.io#321drm: rockchip: dw-dp: add AUX recovery for USB-C DP Alt Mode. by @mingzhangqun in armbian/linux-rockchip#494easepi-r2/a2: fix device tree. by @jjm2473 in armbian/linux-rockchip#491feat(boards): Add Seeed Studio reComputer RK3576/RK3588 DevKit support. by @baorepo in armbian/build#9719Give each TQ SoC family its own LINUXCONFIG. by @schmiedelm in armbian/build#9924Introducing Armbian Imager 2.0. by @SuperKali in armbian/imager#143Milk-V Jupiter disable EEPROM node. by @pyavitz in armbian/build#9944nanopi-r76s: fix slow WiFi by enabling SDIO SDR104. by @SuperKali in armbian/build#9929net: r8169: add device tree based LED configuration for r8125. by @mingzhangqun in armbian/linux-rockchip#497orangepi5-ultra: enable Bluetooth on edge kernel via hci_bcm. by @pdapandapda in armbian/build#9697Revert "rockchip64: fix USB gadget NULL pointer crash in eth_get_drvinfo (6.18 + 7.0)". by @EvilOlaf in armbian/build#9926rockchip64: enable back tm16xx driver for current kernel. by @paolosabatino in armbian/build#9941rockchip64: update "describe PCIe Ethernet controllers" patch for stable MAC (many boards). by @rpardini in armbian/build#9933rtl8192eu: re-enable and fix tons of compilation warnings. by @EvilOlaf in armbian/build#9927SpacemiT: Update K1 boot support. by @pyavitz in armbian/build#9930Treat imx93 as slow hardware. by @schmiedelm in armbian/armbian.github.io#323Update EasePi A2/R2 board configs and device trees for improved hardware support. by @ifroncy01 in armbian/build#9907Update VERSION. by @EvilOlaf in armbian/build#9938View the full article

This week's updates center on new board enablement, Rockchip platform refinements, and tooling and kernel maintenance. Board support expanded across multiple silicon families, with the addition of Seeed Studio reComputer RK3576/RK3588 DevKits and the Anbernic RG DS handheld image. The EasePi A2/R2 received substantial revisions to its board configurations and device trees, alongside a vendor logo transition to Linkease. SpacemiT K1 boot support was updated, and per-SoC LINUXCONFIG separation was introduced for the TQ family to better isolate kernel configurations. Rockchip received the bulk of low-level improvements. Notable changes include AUX recovery for USB-C DP Alt Mode in the dw-dp driver, device-tree-based LED configuration for the r8169/r8125 controllers, and an updated patch ensuring stable PCIe Ethernet MAC addresses across many boards. Additional fixes resolve slow WiFi on the NanoPi R76S via SDIO SDR104, enable Bluetooth on the Orange Pi 5 Ultra edge kernel, and restore the tm16xx driver on current kernels. On the tooling and maintenance side, Armbian Imager 2.0 was released, the mainline kernel was bumped to 7.1-rc6, and the rtl8192eu driver was re-enabled following a cleanup of compilation warnings. A previously merged USB gadget NULL pointer fix was reverted pending further evaluation. #Armbian #EmbeddedLinux #Rockchip #SBC #KernelDevelopment Changesmainline: bump to 7.1-rc6. by @EvilOlaf in armbian/build#9922Add Anbernic RG DS board image and Anbernic vendor logo. by @crackerjacques in armbian/armbian.github.io#326Add jellyfin-ffmpeg release constraints and ip-wrapper for easepi-r2. by @ifroncy01 in armbian/build#9942arm64: dts: overlay: add radxa display 8hd for rock5t. by @Ken-Vamrs in armbian/linux-rockchip#498board-vendor-logos: update EasePi vendor logo to Linkease. by @ifroncy01 in armbian/armbian.github.io#321drm: rockchip: dw-dp: add AUX recovery for USB-C DP Alt Mode. by @mingzhangqun in armbian/linux-rockchip#494easepi-r2/a2: fix device tree. by @jjm2473 in armbian/linux-rockchip#491feat(boards): Add Seeed Studio reComputer RK3576/RK3588 DevKit support. by @baorepo in armbian/build#9719Give each TQ SoC family its own LINUXCONFIG. by @schmiedelm in armbian/build#9924Introducing Armbian Imager 2.0. by @SuperKali in armbian/imager#143Milk-V Jupiter disable EEPROM node. by @pyavitz in armbian/build#9944nanopi-r76s: fix slow WiFi by enabling SDIO SDR104. by @SuperKali in armbian/build#9929net: r8169: add device tree based LED configuration for r8125. by @mingzhangqun in armbian/linux-rockchip#497orangepi5-ultra: enable Bluetooth on edge kernel via hci_bcm. by @pdapandapda in armbian/build#9697Revert "rockchip64: fix USB gadget NULL pointer crash in eth_get_drvinfo (6.18 + 7.0)". by @EvilOlaf in armbian/build#9926rockchip64: enable back tm16xx driver for current kernel. by @paolosabatino in armbian/build#9941rockchip64: update "describe PCIe Ethernet controllers" patch for stable MAC (many boards). by @rpardini in armbian/build#9933rtl8192eu: re-enable and fix tons of compilation warnings. by @EvilOlaf in armbian/build#9927SpacemiT: Update K1 boot support. by @pyavitz in armbian/build#9930Treat imx93 as slow hardware. by @schmiedelm in armbian/armbian.github.io#323Update EasePi A2/R2 board configs and device trees for improved hardware support. by @ifroncy01 in armbian/build#9907Update VERSION. by @EvilOlaf in armbian/build#9938View the full article

Hello everyone! I'm using this patch set from github to run armbian on x88pro13 (which has RK3528 with Mali 450 MP2). Everything seems to work fine (even wifi), but i'm not able to enable hw acceleration on kodi interface (it shows llvmpipe, so it's sw rendering) Do you have any hints on how to do that? Because at the moment i get 80% cpu just for the kodi gui. Thanks!

I see similar issues with some s905x2 and some s905c3 boxes I have. I've never dug into the issue to see what is happening, but the workaround that works for my cases is that when the boot from emmc fails, I boot from an SD card (I have an SD card ready just for this). Then reboot from emmc, and then it usually will boot. For some reason a successful boot from SD clears up something that then allows the emmc to boot properly. This is what works for me, don't know if your situation is the same or different but you can try.

Thank you for sharing this detailed guide and the partition layout. Getting Debian Trixie up and running on a Teclast tablet is an impressive piece of engineering, and your warning about the 1.8V logic levels will definitely save some hardware from getting fried. Have you made any progress with the aic8800 Wi-Fi driver yet? Also, how is the rest of the hardware behaving with the Radxa kernel?

I got a small progress here with a RKNN (TPU). 1. note from previous posts: rk3566-box-demo.dtb looks like does not support our USB. Use rk3566-box-X88PRO20.dtb that other shared. I tried to use the NPU, looked across the forum. Managed to get our .dtb running with the correct settings - however the Kernel didn't had the RKNN packages + it could not link the 'rocket' to our NPU. While the NPU was recognized after my tweaks. Read that it runs only on kernel v. 6.1 from VENDOR - recompiled the kernel for our board, installed it over the existing installation - .dtb didn't run... When I switched to box-demo from the kernel the NPU and RKNN were recognized instantly. I will not attach the kernel itself for now, as it is ~300 Mb, however you can compile it from Armbian: ./compile.sh kernel BOARD=station-m2 BRANCH=vendor \ KERNEL_BTF=no KERNEL_GIT=full it have to be installed like that: dpkg -i linux-image-vendor-rk35xx_*.deb linux-dtb-vendor-rk35xx_*.deb update-initramfs -c -k 6.1.115-vendor-rk35xx Probably will be a task for today to tweak .dtb for this kernel version and get board running with RKNN. I want to try immich with a local image classification.

Some NVMe's just don't play nice with some units. I have one such NVMe, which is why I rarely try to use it. Also u-boot is not set up to look for an infinite amount of $devnum. Currently it is hard coded to look for nvme 0:1. So I suggest moving the NVMe to the first available. According to the boot log you have more than one PCIE link up [ 1.438] PCIE-0: Link up (Gen2-x2, Bus0) <-- Thats where you want to attach the NVMe [ 1.600] PCIE-2: Link up (Gen2-x2, Bus2) Honestly though. It looks like the NVMe you are trying to use isn't compat.

@sven-ola For my next debugging: To make a separate boot MicroSD, how should I go about? I guess I boot from the MicroSD but in single-user mode (how?) and then mount /dev/nvme0n1p1 / . Then, I re-flash the MicroSD with the image from you: dd if=Armbian.. of=/dev/sd0c bs=1M And then create a new Ext4 filesystem on the now-system partition, for use as boot: mkfs.ext4 /dev/sd0a And then move all the boot files there: mv /boot /boot.orig; mkdir /boot; mount /dev/sd0a /boot; cp -rf /boot.orig/* /boot/ And in addition to this, what files should I change and what commands should I run, for the MicroSD to boot to the SSD i.e. /dev/nvme0n1p1 ? (I'd think some file in /boot , perhaps /etc/fstab ) Aside from trying other power supplies, any thoughts about how to get it going would be much appreciated. One thing I should test is disconnect the SSD from the computer and then try to boot the 7.1 kernel Armbian from MicroSD and see if that works.

@Werner here is the URL: https://paste.armbian.com/yoyimafolu

Let us know @johlnx

I did more of a dance with AI and eventually got it working. This was the real repo: https://github.com/radxa-pkg/aic8800 Got the AI to write a summary of the dance. Phase 1: Resolving the Tooling and Environment Dependencies We started with a clean, lightweight system image missing common Linux development tools. We methodically installed the software compilation and packaging toolchain required to handle vendor drivers: Kernel Headers: Replaced the generic linux-headers-$(uname -r) command with the specific architecture branch package (linux-headers-current-arm64) to give the driver access to the Linux kernel API blueprints. Line Ending Conversions: Installed dos2unix to fix internal cross-platform formatting issues within the raw source files. Packaging Toolchain: Installed devscripts, debhelper, and fakeroot to fulfill the minimum environment demands of the dpkg-buildpackage engine. DKMS Engine Helpers: Installed dh-dkms to handle the missing modern virtual package mapping (dh-sequence-dkms). Phase 2: Resolving Kernel Version API Incompatibilities Because the hardware driver code was originally written for older Linux builds, trying to compile it directly against a modern 6.18 kernel threw standard compilation crashes. We bypassed the rigid Debian patch architecture and fixed the source code directly: Signature Alignment: Modified the function argument signature for .get_tx_power in rwnx_main.c to support the newer 5-parameter layout required by the upstream kernel (struct wiphy *wiphy, struct wireless_dev *wdev, int bss_idx, unsigned int link_id, int *mbm). Variable Alignment: Updated the interior variable name pointer within that function definition from dbm to mbm to match modern wireless power unit metrics used in current Linux network subsystems. Phase 3: Bypassing Packaging & Direct Kernel Compilation Rather than battling failing packaging lint tests or restrictive file verification scripts, we pivoted to an elegant, direct implementation: Dropped straight into the target interface folder (src/USB/driver_fw/drivers/aic8800/). Ran a direct raw build command targeting the standalone USB interface module flag: make CONFIG_AIC8800_USB=m. Manually pushed the generated binaries directly into the system kernel storage directory tree using sudo make install and synchronized the dependency layout using depmod -a. Phase 4: Correcting Firmware Pathing & Module Sequence The driver successfully built and registered with the kernel, but the physical USB bus threw initialization timeouts (bus is not up=0). We fixed the underlying hardware communication pipeline: Firmware Relocation: Traced the location of the compiled firmware folder hidden within the repository's package blueprints, and copied the raw firmware files directly into the absolute hardware search path at /lib/firmware/aic8800D80/. Sequential Probing: Cleared out the broken module states and forced the hardware interface modules to load in their structural order—giving the hardware bus loader helper (aic_load_fw) a 2-second sleep window to awaken the USB links before initializing the operational wireless adapter engine (aic8800_fdrv).

You will have to make a choice which bootloader firmware you use. And then also which boot method and/or bootmanager. Armbian images for Rockchip SBC's are as simple as possible, so only 1 OS, no ad-hoc kernel selection. That means 1 partition for rootfs, no others. Different methods have different advantages and disadvantages. If you want other boot method and/or bootmanager, you will need to add a boot partition yourself, usually FAT formatted and type 0xEF00 (called ESP). The Armbian rockchip64 supports it all, no problem. Especially the Rock5B, which is more or less the blue-print of high-end ARM64 SBC. But all this own custom action also make it not Armbian anymore, but just a generic UEFI ARM64 computer. Where you could also boot from a CD-ROM .iso image and run a traditional Linux distro installer like used on x86 PC's.

I did a apt upgrade that messed up my set up, so I have recently (as in two hours ago) reinstalled armbian on on my dragon q6a. Unlike the previous set up, I have not been able to connect to my wifi. Did a bit of a dance with AI help and still failed, but it looks like the wifi module is directly not found. nmcli device returns ``` DEVICE TYPE STATE CONNECTION enp1s0 ethernet unmanaged -- lo loopback unmanaged -- ``` lsusb returns Bus 001 Device 005: ID a69c:8d80 aicsemi AIC Wlan So I guess that's the wifi hardware and AI claims my system does not have the drivers. AI then sent me on a search for the drivers, but it was to a repo that does not exist, so kind of looking for help here now!

I had once put EDK2 on the SPI flashed and it seems to run fine, I was able to enter the menu. > i used this specific armbian image But Armbian images use U-boot right? So if it boot from the SD-card EDK2 shouldn't launch right. Armbian images are UEFI compatible?

You made me curious, so I rebooted for the first time after my previous report to activate my current versions. I' m now at kernel 7.0.0-0.rc1.15.fc45.aarch64 and U-Boot 2026.07-rc1 (May 22 2026 - 00:00:00 +0000). No regressions can be observed and it works as fast as before.

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

Hello All.. I am trying to get rknpu working properly. I have resolute minimal install with 6.1 vendor kernel installed. Default install does not have `/dev/rknpu` and shows error with loading the rknpu driver. Can any one help resolve this? This is with fresh install of the OS on the NVME drive: There is no NPU option in the dtb list for orangepi5plus. PRETTY_NAME="Armbian 26.5.1 resolute" NAME="Ubuntu" VERSION_ID="26.04" VERSION="26.04 (Resolute Raccoon)" VERSION_CODENAME=resolute ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=resolute LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 26.5.1 resolute" This is the error in dmesg [ 15.981999] RKNPU fdab0000.npu: Adding to iommu group 0 [ 15.982175] RKNPU fdab0000.npu: RKNPU: rknpu iommu is enabled, using iommu mode [ 15.982308] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.985241] RKNPU fdab0000.npu: Looking up mem-supply from device tree [ 15.988551] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdab0000-0xfdabffff] [ 15.988583] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdac0000-0xfdacffff] [ 15.988603] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdad0000-0xfdadffff] [ 15.989174] [drm] Initialized rknpu 0.9.8 20240828 for fdab0000.npu on minor 1 [ 15.993547] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.996066] RKNPU fdab0000.npu: RKNPU: bin=0 [ 15.996288] RKNPU fdab0000.npu: leakage=8 [ 15.996320] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 15.996356] debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! [ 16.005738] RKNPU fdab0000.npu: pvtm=868 [ 16.011925] RKNPU fdab0000.npu: pvtm-volt-sel=3 [ 16.012005] RKNPU fdab0000.npu: Looking up rknpu-supply from device tree [ 16.012037] debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present! [ 16.012656] RKNPU fdab0000.npu: Looking up mem-supply from device tree [ 16.014725] RKNPU fdab0000.npu: avs=0 [ 16.014836] RKNPU fdab0000.npu: rockchip_pvtpll_set_volt_sel: error cfg clk_id=6 voltsel (-1) [ 16.015007] RKNPU fdab0000.npu: l=15000 h=85000 hyst=5000 l_limit=0 h_limit=800000000 h_table=0

Orange Pi 5 Ultra HDMI RX no video when connecting Walksnail VTX Ascent. When I connect Walksnail Ascent VRX, the picture is fine, but when I connect VTX Ascent to VRX, the system doesn't see the HDMI RX. Specifically, it sees the source but can't lock it. The settings are set to 1080p60. I've tried different kernel and OS builds, but the result remains the same. What are the ways to solve this problem at the software level, since I specifically chose the Orange Pi 5 Ultra because of its built-in HDMI IN. [ 41.859256] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 42.371741] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 43.358027] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 43.358032] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 47.623748] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 48.131739] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 49.106851] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 49.106858] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 53.409063] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 53.921736] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 54.876109] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 54.876117] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 59.155931] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 59.678402] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 60.623901] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 60.623907] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 64.892299] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 65.411737] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 66.391898] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 66.391904] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 [ 70.706000] fdee0000.hdmirx-controller: Vertical Sync threshold reached interrupt 0x2 [ 71.225068] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_delayed_work_audio: enable audio [ 72.155904] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing signal not lock, tmds_clk_ratio:0 [ 72.155910] fdee0000.hdmirx-controller: hdmirx_wait_lock_and_get_timing mu_st:0x2, scdc_st:0x1, dma_st10:0x10 That's just when the Walksnail VRX ascension begins on orangepi@orangepi5-ultra:~$ v4l2-ctl -d "$DEV" --get-dv-timings Video timings: Active width: 1280 Active height: 720 Total width: 1650 Total height: 750 Frame format: progressive Polarity: +vsync +hsync Pixel frequency: 74250000 Hz (60.00 frames per second) Horizontal front panel: 110 Horizontal synchronization: 40 Horizontal rear panel: 220 Vertical front panel: 5 Vertical synchronization: 5 Vertical screen: 20 Standards: CTA-861 CTA-861 VIC: 4 Flags: frame rate can be reduced by 1/1.001, CE-video, has CTA-861 VIC Here is an example of how you can connect Walksnail VTX Ascent to VRX Ascent - HDMI in Orange Pi 5 Ultra orangepi@orangepi5-ultra:~$ v4l2-ctl -d "$DEV" --query-dv-timings VIDIOC_QUERY_DV_TIMINGS: error: Locking not available Active width: 0 Active height: 0 Total width: 0 Total height: 0 Frame format: Progressive

We're releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you'll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up configured on first boot. No monitor, no keyboard, none of that blind first login. Set it up once. It configures itself.This is the big change in 2.0. You build a profile in settings: username and password, an SSH key, your Wi-Fi network and country code, timezone, locale, shell. Imager writes it straight into the image's filesystem while it flashes. Power on the board, it reads the profile and brings itself up. Qualcomm boards over QDL get the same treatment. It's the difference between "flash, hook up a screen and keyboard, sit through the setup" and "flash, slot the card, switch on." I didn't expect to care this much about it, and now I can't flash without it. Pick everything on one screenThe old pop-up windows are gone. In their place is a single animated flow: manufacturer, board, OS, device, all on one page that moves with you. You page through the board and vendor grids, the distro logos are drawn by hand, and the app glides instead of slamming between screens. Settings got the same redesign. So did the cache manager, which now shows where your gigabytes actually went, by category, and clears them in a tap. Know what you're writing before you write itEvery image tells you what it is up front: build date, badges for the desktop and the kernel branch, a label when it ships with something preinstalled like the SDK build, openHAB, or Kali. Anything you've already downloaded carries a small check, so you don't pull it twice. If you want the trunk rolling releases, there's a filter for them, with a plain warning before you commit. And images that can't be written to a card, like the VM disk formats, simply aren't in the list. Every write, checked byte for byteThe download is verified against its SHA256. After writing, the app reads the card back and compares it to the source, byte for byte. While that runs, your board floats over a warm glow that follows the progress, with one line telling you the stage instead of a wall of numbers. When the check turns green, it's because the data on the card matches. Not because we're optimistic. Bring your own images, online or offlineHave an image of your own? Drop it in. We handle img, iso, xz, gz, bz2, and zst, and decompress before writing. Lose your connection partway through the day and Imager still works: the offline mode was reworked so your cache and your own files stay one click away. The same app on Mac, Linux, and WindowsSame look and behavior on all three. On Mac it's a single universal build for Intel and Apple Silicon. Pick a light theme, a dark one, or let it follow the system. Eighteen languages, chosen automatically from your locale. Free and open source, the way it started. Get itArmbian Imager 2.0 is available now, free, on Mac, Linux, and Windows. It does the same job it always has, writing a good image to a card. The new part is what happens after: you power the board on, and it's already yours. Download Armbian Imager 2.0 View the full article

We're releasing Armbian Imager 2.0. We rebuilt the whole thing, the interface and the flashing engine underneath it. The part you'll notice first: your board boots already set up. Username, password, Wi-Fi, timezone, language. You tell Imager once, it writes that into the image, and the board comes up configured on first boot. No monitor, no keyboard, none of that blind first login. Set it up once. It configures itself.This is the big change in 2.0. You build a profile in settings: username and password, an SSH key, your Wi-Fi network and country code, timezone, locale, shell. Imager writes it straight into the image's filesystem while it flashes. Power on the board, it reads the profile and brings itself up. Qualcomm boards over QDL get the same treatment. It's the difference between "flash, hook up a screen and keyboard, sit through the setup" and "flash, slot the card, switch on." I didn't expect to care this much about it, and now I can't flash without it. Pick everything on one screenThe old pop-up windows are gone. In their place is a single animated flow: manufacturer, board, OS, device, all on one page that moves with you. You page through the board and vendor grids, the distro logos are drawn by hand, and the app glides instead of slamming between screens. Settings got the same redesign. So did the cache manager, which now shows where your gigabytes actually went, by category, and clears them in a tap. Know what you're writing before you write itEvery image tells you what it is up front: build date, badges for the desktop and the kernel branch, a label when it ships with something preinstalled like the SDK build, openHAB, or Kali. Anything you've already downloaded carries a small check, so you don't pull it twice. If you want the trunk rolling releases, there's a filter for them, with a plain warning before you commit. And images that can't be written to a card, like the VM disk formats, simply aren't in the list. Every write, checked byte for byteThe download is verified against its SHA256. After writing, the app reads the card back and compares it to the source, byte for byte. While that runs, your board floats over a warm glow that follows the progress, with one line telling you the stage instead of a wall of numbers. When the check turns green, it's because the data on the card matches. Not because we're optimistic. Bring your own images, online or offlineHave an image of your own? Drop it in. We handle img, iso, xz, gz, bz2, and zst, and decompress before writing. Lose your connection partway through the day and Imager still works: the offline mode was reworked so your cache and your own files stay one click away. The same app on Mac, Linux, and WindowsSame look and behavior on all three. On Mac it's a single universal build for Intel and Apple Silicon. Pick a light theme, a dark one, or let it follow the system. Eighteen languages, chosen automatically from your locale. Free and open source, the way it started. Get itArmbian Imager 2.0 is available now, free, on Mac, Linux, and Windows. It does the same job it always has, writing a good image to a card. The new part is what happens after: you power the board on, and it's already yours. Download Armbian Imager 2.0 View the full article

SoC:ik316-h board: IK316Q-EMCP_V4.1 i belive it's apart of the h6 familly, correct me if i'm wrong. Well, i'm trying to boot from a sd card, but it doesn't work, i tried the toothpick methof but it still don't work. I tried with the sd and without the sd card, but it doesn't enter into android recovery mode, the only way i can get into fastboot is by using adb, however if i try to enter the bootloader by selecting it on the andorid recovery or fastboot menu it just crashes. Do you guys know any way of how can i proceed? Will be better if i change the firmware? Should i just buy ice cream and cry in the shower? I need help, the img i'm using is Armbian_community_26.2.0-trunk.886_X96q_trixie_current_6.18.28_minimal.img, because i believe it's the most compatible to my board. Feel free to ask any questions.

Can't confirm, still the same thing. U-boot built 7 days ago (linux-u-boot-odroidm1-edge/sid,now 26.8.0-trunk.105 arm64) # uname -r 7.0.11-edge-rockchip64 # grep -a --null-data U-Boot /dev/mtd0ro U-Boot SPL 2026.01_armbian-2026.01-S127a-Pb401-H8652-Vab81-Bd0d2-R448a (May 31 2026 - 05:41:25 +0000) # grep -a --null-data U-Boot /dev/mmcblk1 U-Boot SPL 2026.01_armbian-2026.01-S127a-Pb401-H8652-Vab81-Bd0d2-R448a (May 31 2026 - 05:41:25 +0000) 100 Mbps link still performs much better by some unknown reason. Hmm. (I've already tested the cable, any other computer/laptop transmits the data just fine at full Gigabit speed)