Search the Community

Found 188 results

1. Orange Pi 5 Ultra: Armbian 26.11 / Linux 6.18.60 test report and maintainer interest
   

   Orange Pi 5 Ultra: Armbian 26.11 / Linux 6.18.60 test report and maintainer interest

   KingFalse posted a topic in Rockchip

   Hi everyone, I have physical access to an Orange Pi 5 Ultra with 16 GB RAM and would like to help with testing and maintenance of this board. Here is my first round of hardware testing on the current/mainline image. I am posting the working features, reproducible problems and remaining gaps separately. This is an initial test report, not a release sign-off. Image and test environmentBoard: Orange Pi 5 Ultra, RK3588, 16 GB RAM. Image: Armbian community 26.11.0-trunk.120, Ubuntu 26.04 Resolute, GNOME/Wayland, booted from microSD. Kernel: 6.18.60-current-rockchip64. Image build commit: c24ea08f8759a37aaa83a101774582c37c18eda6. Kernel, DTB and BSP packages: 26.11.0-trunk.120. Mesa: 26.0.8-1ubuntu0.3. Storage: 64 GB SDXC card using SDR104 at approximately 148.5 MHz; Samsung SSD 980 500 GB on PCIe 3.0 x4; Toshiba MQ04UBF100 1 TB USB hard disk detected at SuperSpeed 5000M. Ethernet: RTL8125B using r8169, linked to a 1 GbE LAN peer. Cooling fan present. PSU model/specification has not yet been recorded. Tests were run on 5–6 November 2026, UTC+8, using remote shell/Python automation and local hands-on cable/desktop checks. A baseline package list and boot log were saved before testing. The desktop updater subsequently updated userspace packages, including libc6 from 2.43-2ubuntu2.3 to 2.43-2ubuntu2.4. The recorded kernel/DTB packages and Mesa version remained as listed above. This should therefore not be treated as a completely untouched-image test for every later result. Additional test utilities were unpacked into a separate test directory. I do not yet have an armbianmonitor -u upload URL from this session. Redacted baseline boot, hardware and package information is included with the test evidence; a formal support report is still incomplete. Completed checksBoot and desktop: SD boot, GNOME/Wayland desktop, HDMI output, USB keyboard and mouse were usable. This covers this desktop image only, not a separate minimal/CLI image. GPU: accelerated OpenGL renderer reported Mali-G610 MC4 (Panfrost). glmark2 output validation passed. Vulkan enumeration with the Panfrost ICD and a 240-frame Wayland vkcube run completed successfully. Three short glmark2 scenes also completed; this was not the full default performance benchmark. RAM: memtester completed one full pass over 2 GiB with exit status 0 in 836.51 seconds. The highest sampled temperature during that test was 53.6°C. This is not exhaustive coverage of all 16 GB. CPU policy: three cpufreq policies were present, with observed peaks of 1.8 / 2.4 / 2.4 GHz during the memory test. The desktop tuning profile and ext4 commit=15 setting were present. A full CPU/VM soak result is still missing, as noted below. RTC: HYM8563 time reads worked. A future, minute-aligned alarm triggered the RTC hardware interrupt at the requested RTC timestamp; its IRQ counter increased from 0 to 1. This was an awake-system alarm test, not a suspend wake-up or battery-backed power-off retention test. Ethernet: TCP receive to the board was approximately 940 Mb/s and transmit from the board approximately 764 Mb/s. A bidirectional run also completed. IPv4, IPv6 and 1500-byte-MTU ping checks passed. The peer was limited to 1 GbE, so 2.5 GbE throughput was not validated. Storage checksfio 3.41 was used for bounded tests. SD and USB file tests used 1 MiB blocks, direct I/O, libaio queue depth 16 and CRC32C write/read verification. The NVMe test used direct, read-only access with a 4 GiB working set for 15 seconds. Rates below are decimal MB/s. Device / scope Write Read Result SD, 2 GiB file 24.75 MB/s 65.81 MB/s CRC32C verification passed USB hard disk, 1 GiB file, first USB 3 port 59.08 MB/s 138.65 MB/s CRC32C verification passed NVMe, read-only Not tested 1403.87 MB/s Read test passed; health queries completed The SD and USB 4 KiB random-read tests also completed. No new storage-related kernel errors were found during this test interval. These tests do not cover the entire capacity of the media. NVMe write verification and the second USB 3 port remain untested. Open finding 1: onboard Wi-Fi interface is missingAt baseline, Ethernet and Bluetooth were present but no WLAN interface or wireless PHY appeared. The installed bcmdhd-sdio-dkms package was built for the running kernel, while the SDIO bus had no enumerated device. The live device tree contained: mmc@fe2d0000 { status = "disabled"; };Observed package/driver state: bcmdhd-sdio-dkms: 101.10.591.52.27-10 bcmdhd-sdio/101.10.591.52.27-10, 6.18.60-current-rockchip64, aarch64: installed iw dev / iw phy: no wireless interface or PHY listed /sys/bus/sdio/devices/: emptyThe vendor board DTS contains SDIO enablement and a Wi-Fi power sequence. Missing board-level SDIO/power-sequence description is a suspect; no proposed fix or overlay has been runtime-tested in this session. Open finding 2: HDMI input self-loop did not lockWith no independent HDMI source available, I connected this board's HDMI OUT to its HDMI IN. A fullscreen colour-bar pattern was generated, and the receiver was given the v4l2-ctl HDMI EDID preset. DRM state confirmed a 1920×1080 at 60 Hz RGB 8 bpc transmitter mode, with a 148.5 MHz TMDS clock. The receiver reported power_present=1, but v4l2-ctl --query-dv-timings failed with “No locks available”. The kernel logged: hdmirx_phy_register_write wait cr write done failed hdmirx_controller_init wait timer base lock failed hdmirx_query_dv_timings: signal is not lockedThe HDMI RX HDMI/DMA IRQ counters stayed at zero while the 5V-detect GPIO IRQ counter increased. Unloading/reloading synopsys_hdmirx and reapplying the test EDID reproduced the same result. The original receiver EDID and monitor connection were restored afterward. This is a reproducible self-loop observation on this setup, not proof that every external HDMI source will fail. Testing with an independent source and checking a clean cold boot remain necessary. Relevant earlier changes include #10172 and the 6.18 patch adjustment #10180. Incomplete and intentionally omitted checksA 15-minute all-CPU plus 4 GiB VM verification run was started, but no final completion record has been collected. The last collected progress line was around 58 seconds. I am not counting this soak as passed. Later, new SSH connections were closed before authentication while the board still answered LAN pings. The cause has not been established, and I am not attributing it to the load test or kernel without further evidence. Bluetooth firmware loading, discovery and three rfkill recovery cycles were observed; pairing and data transfer were not validated. Further Bluetooth testing was intentionally skipped. Actual audio playback/capture, the second USB 3 port, repeated warm/cold boot recovery, RTC power-off retention, other images/kernel branches and additional header/camera interfaces remain outside this completed test set. Maintenance interestI would like to contribute release-image testing and reproducible board reports for the Orange Pi 5 Ultra. In particular, #10673 explicitly noted missing Ultra/Linux 6.18 runtime coverage, and #11157 reported no board hardware testing for the CPU policy changes. The observations above provide some additional runtime evidence, with the limitations stated. I have saved the scripts, package inventories and logs, and can provide specific redacted excerpts. Guidance on the highest-priority follow-up tests and the board-maintainer application process would be appreciated. KingFalse orangepi5-ultra-6.18-first-round-evidence.zip

   • Yesterday at 03:49 AM1 day
   • • orangepi5-ultra
2. [Collabora] - Panfrost is now using Kraid!
   

   [Collabora] - Panfrost is now using Kraid!

   RSS Bot posted a topic in SBC News

   Kraid is now the default Panfrost compiler for Valhall and newer Mali GPUs, delivering major reductions in shader instructions, spilling, compile time, and memory use while providing a stronger foundation for future compiler optimization. View the full article

   • October 26Oct 26
3. [Armbian newsletter] - Github Highlights
   

   [Armbian newsletter] - Github Highlights

   admin posted a topic in SBC News

   This week's work centers on expanded board support, Rockchip and Realtek platform maturation, and continued refinement of installation and BSP tooling. New hardware enablement spans several SoC families. Initial build support arrives for the Altera Agilex 5 SoCDK, Banana Pi R3 Mini, Firefly AIBOX-K3, and the Allwinner H5 PBS TV Stick, while a new realtek-rtd129x family brings mainline kernel and U-Boot to the Banana Pi W2. The MangoPi MQ Pro gains Debian GRUB EFI boot and a proper maintainer, and the Radxa CM5-IO transitions to mainline kernel and U-Boot. Supporting firmware updates include Tegra210 USB, GPU and VIC blobs, Amlogic VDEC firmware, Realtek rtl8261c, and Qualcomm EDK2 firmware for Radxa boards. Rockchip receives sustained attention across kernel branches, with RK3576 Panfrost GPU overlays, vendor-next OPP and GPU-name corrections for RK356x Panfrost, RK356x suspend fixes for USB and NVMe, and patch repairs for the 6.18 and 7.3 trees. The new Realtek RTD129x family lands multiple stabilization patches covering hwnat RX overflow, watchdog timeout handling, and the r8169soc driver. Sunxi edge advances to 7.3, A523 gains HDMI audio DTS, and Meson moves VIM4 to 7.3 with GPU and audio support. On the user-facing side, armbian-install gains a standalone mode for U-Boot boot disks and board-defined firmware naming, while the BSP layer improves conffile handling, preserves user edits to periodic configuration, and defers armbianEnv.txt rewrites. The imager stops mislabeling every target as an SD card, mainline U-Boot advances to v2026.10, and the documentation site adds DUT inventory, board pinouts, schematics, and installation instructions. #Armbian #EmbeddedLinux #Rockchip #Realtek #UBoot ChangesAdd board and vendor logo images for the Altera Agilex5 SoCDK. by @dinguyen702 in armbian/armbian.github.io#483Add board image for Banana Pi BPI-W2. by @igorpecovnik in armbian/armbian.github.io#496Add board image for pbstvstick. by @JulioRamos0 in armbian/armbian.github.io#495Add board instructions. by @igorpecovnik in armbian/armbian.github.io#508Add board pinouts and schematics. by @igorpecovnik in armbian/armbian.github.io#507Add DKMS support. by @Vladnwx in armbian/uwe5622#22Add DUT inventory workflow (NetBox -> data branch). by @igorpecovnik in armbian/armbian.github.io#501Add initial board configuration for Firefly AIBOX-K3. by @leoppark94 in armbian/build#10956add Shaghal isologo. by @JulioRamos0 in armbian/armbian.github.io#497add vendor-next to ci. by @EvilOlaf in armbian/uwe5622#26apt-cacher-ng: fetch Armbian repositories from mirrors directly. by @igorpecovnik in armbian/docker-armbian-build#43arm64: dts: rockchip: add NanoPi M6 V2. by @igorpecovnik in armbian/linux-rockchip#584arm64: dts: rockchip: add RK3576 Panfrost GPU overlay. by @HeyMeco in armbian/linux-rockchip#592arm64: dts: rockchip: mixtile-blade3: raise the USB-C1 sink PDOs to 3A. by @evtest-hash in armbian/linux-rockchip#590arm64: dts: rockchip: retune reComputer RK3588 devkit fan curve. by @rpardini in armbian/linux-rockchip#588armbian-add-overlay: quote paths, run #include overlays through cpp. by @iav in armbian/build#10981armbian-firstlogin: write Wi-Fi password as YAML literal block. by @jfcabral in armbian/build#10996armbian-hardware-optimization: only rewrite armbianEnv.txt when it changes. by @pablo-cabrera in armbian/build#11029armbian-install: add a standalone mode for disks u-boot boots from. by @SuperKali in armbian/configng#1065armbian-install: let boards name the firmware they flash. by @SuperKali in armbian/configng#1064armbian-led-state: wait for LEDs registered by modules. by @igorpecovnik in armbian/build#10987armbian-upgrades: set APT::Periodic::Enable. by @igorpecovnik in armbian/configng#1059armbian-upgrades: show the checkboxes in the unattended-upgrade dialog. by @igorpecovnik in armbian/configng#1063bananapiw2: u-boot: use 1 GiB with one DRAM controller, turn on the eth1 LEDs. by @igorpecovnik in armbian/build#11026board-images: add MangoPi MQ Pro. by @igorpecovnik in armbian/armbian.github.io#500board-images: add Pine64 Quartz64 Zero. by @pablo-cabrera in armbian/armbian.github.io#506board: add Agilex 5 SoCDK build support. by @dinguyen702 in armbian/build#10938board: add Banana Pi R3 Mini. by @SuperKali in armbian/build#10678board: mixtile-edge2: update mainline DTS for rockchip64. by @evtest-hash in armbian/build#11045board: sunxi: add Allwinner H5 PBS TV Stick (pbstvstick) support. by @JulioRamos0 in armbian/build#10986boards: fix broken module-devkit build, add resolute btattach workaround. by @Lesords in armbian/build#11009bsp/armbian-ramlog - allow armbian-ramlog to recognize .lz files. by @tabrisnet in armbian/build#10993bsp: keep user edits to 02-armbian-periodic. by @igorpecovnik in armbian/build#10985bsp: skip a conffile that an extension removed from the BSP. by @igorpecovnik in armbian/build#11017bsp: write the conffiles list after the hooks, and check the files are there. by @igorpecovnik in armbian/build#11008ci: enable remaining uwe related kernel modules. by @EvilOlaf in armbian/uwe5622#27cix-6.18: rebase SCMI ACPI patch onto 6.18.57. by @SuperKali in armbian/build#11016community: build orangepi4pro from the manual list. by @igorpecovnik in armbian/armbian.github.io#499download-external: fetch arch-independent debs from GitHub releases. by @SuperKali in armbian/armbian.github.io#503drop kernel configs no longer referenced. by @EvilOlaf in armbian/build#11032dut-inventory: trigger web directory rebuild after data update. by @igorpecovnik in armbian/armbian.github.io#502external: add Radxa EDK2 firmware for Qualcomm boards. by @SuperKali in armbian/os#493fix(flash): stop calling every target an SD card. by @SuperKali in armbian/imager#223Index board pinouts, schematics and instructions in armbian-images.json. by @igorpecovnik in armbian/armbian.github.io#509JetHome: Add board image for JetHub D3 (j310). by @QwaSeeK in armbian/armbian.github.io#493kickpi-k2b-v2: fix 1G Ethernet packet loss and enable 1512 MHz OPP. by @Novice-PG in armbian/build#11014mangopi-mq: boot through Debian GRUB EFI. by @khaliforce in armbian/build#10925mangopi-mq: name the board MQ Pro, add a maintainer and a test target. by @igorpecovnik in armbian/build#11001meson-s4t7: replace current (7.1) with edge (7.3), add VIM4 GPU and audio. by @igorpecovnik in armbian/build#10984meson64-7.3: aiu: keep the HDMI source bounds check. by @iav in armbian/build#10982meson64-7.3: phylink WoL: give the MAC the PHY's SecureOn password. by @iav in armbian/build#10983meson: add vdec firmware from linux-firmware. by @igorpecovnik in armbian/firmware#146mvebu: edge: Helios4 OLED via the kernel ssd130x driver. by @neheb in armbian/build#11002nightly: build Khadas VIM1S/VIM4 on edge, add GNOME mid desktop. by @igorpecovnik in armbian/armbian.github.io#498nvidia: add Tegra210 USB, GPU and VIC firmware. by @igorpecovnik in armbian/firmware#148odroidhc4: u-boot: power-cycle the SD card after a watchdog reset. by @iav in armbian/build#10992ping-unresolved-reviews: wait 48 hours before a ping. by @igorpecovnik in armbian/armbian.github.io#494Radxa Dragon Q6A: expose the SPI NOR and update firmware from armbian-install. by @SuperKali in armbian/build#11007radxa-cm5-io: u-boot: fix SPI image build. by @igorpecovnik in armbian/build#10999realtek-rtd129x: add family and BananaPi W2 with mainline kernel and u-boot. by @igorpecovnik in armbian/build#10988realtek-rtd129x: hwnat: fix RX buffer overflow on eth1. by @igorpecovnik in armbian/build#11022realtek-rtd129x: r8169soc: drop CSI access, log link changes once. by @igorpecovnik in armbian/build#11027realtek-rtd129x: watchdog: allow timeouts above the hardware limit. by @igorpecovnik in armbian/build#11023remove orphaned u-boot patches. by @EvilOlaf in armbian/build#11033Revert "drivers: net: wireless: add aic8800 sdio support". by @rpardini in armbian/linux-rockchip#587rk356x: vendor-next: make Panfrost work (OPP masks, GPU names). by @lukaszsobala in armbian/linux-rockchip#586rk35xx-vendor: enable ES8389 codec for NanoPi M6 V2. by @igorpecovnik in armbian/build#10980rockchip-6.18: fix pm-domains patch after 6.18.y update. by @igorpecovnik in armbian/build#11012rockchip-7.3: fix general-rockchip-various-fixes for 7.3-rc7. by @igorpecovnik in armbian/build#10978rockchip64-6.18: fix broken iommu driver patch. by @EvilOlaf in armbian/build#11010rockchip64-7.3: helios64: drop DTS properties that nothing reads. by @iav in armbian/build#11030rockchip64-7.3: helios64: split add-board-helios64.patch into numbered patches. by @iav in armbian/build#11004rockchip64-7.3: RK356x: suspend with USB and NVMe. by @iav in armbian/build#11005rockchip64: drop the rk_crypto2 (montjoie) crypto engine series. by @xfournet in armbian/build#10969rtd129x: add CODA980 (VE1) firmware. by @igorpecovnik in armbian/firmware#147rtl_nic: add rtl8261c.bin from linux-firmware. by @iav in armbian/firmware#145runner-cleanup: remove corrupt apt-cacher-ng by-hash entries. by @igorpecovnik in armbian/configng#1062Simplify the odroidxu4 rtl8821cu fix. by @belegdol in armbian/build#11021sophgo-sg200x: add camera support for the Milk-V Duo S J1 and J2 connectors. by @leafpmpmp in armbian/build#10936sun60iw2: install the patched Xorg only for the X11 desktops. by @igorpecovnik in armbian/build#11000sunxi-6.18: sun55i-iommu: pass old domain to attach_dev. by @EvilOlaf in armbian/build#11011sunxi-7.2: a523 HDMI audio DTS (I2S2 -> DW-HDMI, playback-only). by @juanesf in armbian/build#10913sunxi: bump edge to 7.3. by @EvilOlaf in armbian/build#11031u-boot: mainline: v2026.10 - open the floodgates. by @rpardini in armbian/build#10976u-boot: ship BOOTLOADER_BOOTS_FROM in platform_install.sh. by @SuperKali in armbian/build#11025uboot: enable EEPROM MAC sourcing for reComputer RK3576 Module Dev Kit. by @Lesords in armbian/build#10990unisocwifi: size the remaining reply buffers with sizeof (-Wvla). by @lukaszsobala in armbian/uwe5622#24Update odroidxu4-current to 6.6.159. by @belegdol in armbian/build#11013Update the ELTAY RM66 photo. by @RiPetitor in armbian/armbian.github.io#504uwe5622: bump pinned commit hash. by @EvilOlaf in armbian/build#10989uwe5622: open files from the init root on kernel 7.3. by @lukaszsobala in armbian/uwe5622#23vendor-next: Fix AIC8800 bug. by @HeyMeco in armbian/build#10977wireless: apply the RTL8821CU 6.6.157 fix only where the driver exists. by @igorpecovnik in armbian/build#11019Automatic refresh repository README. by @igorpecovnik in armbian/docker-armbian-build#41radxa-cm5-io: mainline kernel & u-boot. by @JohnTheCoolingFan in armbian/build#10979View the full article

   • October 20Oct 20
4. [News from Armbian] - Github Highlights
   

   [News from Armbian] - Github Highlights

   RSS Bot posted a topic in SBC News

   This week's work centers on expanded board support, Rockchip and Realtek platform maturation, and continued refinement of installation and BSP tooling. New hardware enablement spans several SoC families. Initial build support arrives for the Altera Agilex 5 SoCDK, Banana Pi R3 Mini, Firefly AIBOX-K3, and the Allwinner H5 PBS TV Stick, while a new realtek-rtd129x family brings mainline kernel and U-Boot to the Banana Pi W2. The MangoPi MQ Pro gains Debian GRUB EFI boot and a proper maintainer, and the Radxa CM5-IO transitions to mainline kernel and U-Boot. Supporting firmware updates include Tegra210 USB, GPU and VIC blobs, Amlogic VDEC firmware, Realtek rtl8261c, and Qualcomm EDK2 firmware for Radxa boards. Rockchip receives sustained attention across kernel branches, with RK3576 Panfrost GPU overlays, vendor-next OPP and GPU-name corrections for RK356x Panfrost, RK356x suspend fixes for USB and NVMe, and patch repairs for the 6.18 and 7.3 trees. The new Realtek RTD129x family lands multiple stabilization patches covering hwnat RX overflow, watchdog timeout handling, and the r8169soc driver. Sunxi edge advances to 7.3, A523 gains HDMI audio DTS, and Meson moves VIM4 to 7.3 with GPU and audio support. On the user-facing side, armbian-install gains a standalone mode for U-Boot boot disks and board-defined firmware naming, while the BSP layer improves conffile handling, preserves user edits to periodic configuration, and defers armbianEnv.txt rewrites. The imager stops mislabeling every target as an SD card, mainline U-Boot advances to v2026.10, and the documentation site adds DUT inventory, board pinouts, schematics, and installation instructions. #Armbian #EmbeddedLinux #Rockchip #Realtek #UBoot ChangesAdd board and vendor logo images for the Altera Agilex5 SoCDK. by @dinguyen702 in armbian/armbian.github.io#483Add board image for Banana Pi BPI-W2. by @igorpecovnik in armbian/armbian.github.io#496Add board image for pbstvstick. by @JulioRamos0 in armbian/armbian.github.io#495Add board instructions. by @igorpecovnik in armbian/armbian.github.io#508Add board pinouts and schematics. by @igorpecovnik in armbian/armbian.github.io#507Add DKMS support. by @Vladnwx in armbian/uwe5622#22Add DUT inventory workflow (NetBox -> data branch). by @igorpecovnik in armbian/armbian.github.io#501Add initial board configuration for Firefly AIBOX-K3. by @leoppark94 in armbian/build#10956add Shaghal isologo. by @JulioRamos0 in armbian/armbian.github.io#497add vendor-next to ci. by @EvilOlaf in armbian/uwe5622#26apt-cacher-ng: fetch Armbian repositories from mirrors directly. by @igorpecovnik in armbian/docker-armbian-build#43arm64: dts: rockchip: add NanoPi M6 V2. by @igorpecovnik in armbian/linux-rockchip#584arm64: dts: rockchip: add RK3576 Panfrost GPU overlay. by @HeyMeco in armbian/linux-rockchip#592arm64: dts: rockchip: mixtile-blade3: raise the USB-C1 sink PDOs to 3A. by @evtest-hash in armbian/linux-rockchip#590arm64: dts: rockchip: retune reComputer RK3588 devkit fan curve. by @rpardini in armbian/linux-rockchip#588armbian-add-overlay: quote paths, run #include overlays through cpp. by @iav in armbian/build#10981armbian-firstlogin: write Wi-Fi password as YAML literal block. by @jfcabral in armbian/build#10996armbian-hardware-optimization: only rewrite armbianEnv.txt when it changes. by @pablo-cabrera in armbian/build#11029armbian-install: add a standalone mode for disks u-boot boots from. by @SuperKali in armbian/configng#1065armbian-install: let boards name the firmware they flash. by @SuperKali in armbian/configng#1064armbian-led-state: wait for LEDs registered by modules. by @igorpecovnik in armbian/build#10987armbian-upgrades: set APT::Periodic::Enable. by @igorpecovnik in armbian/configng#1059armbian-upgrades: show the checkboxes in the unattended-upgrade dialog. by @igorpecovnik in armbian/configng#1063bananapiw2: u-boot: use 1 GiB with one DRAM controller, turn on the eth1 LEDs. by @igorpecovnik in armbian/build#11026board-images: add MangoPi MQ Pro. by @igorpecovnik in armbian/armbian.github.io#500board-images: add Pine64 Quartz64 Zero. by @pablo-cabrera in armbian/armbian.github.io#506board: add Agilex 5 SoCDK build support. by @dinguyen702 in armbian/build#10938board: add Banana Pi R3 Mini. by @SuperKali in armbian/build#10678board: mixtile-edge2: update mainline DTS for rockchip64. by @evtest-hash in armbian/build#11045board: sunxi: add Allwinner H5 PBS TV Stick (pbstvstick) support. by @JulioRamos0 in armbian/build#10986boards: fix broken module-devkit build, add resolute btattach workaround. by @Lesords in armbian/build#11009bsp/armbian-ramlog - allow armbian-ramlog to recognize .lz files. by @tabrisnet in armbian/build#10993bsp: keep user edits to 02-armbian-periodic. by @igorpecovnik in armbian/build#10985bsp: skip a conffile that an extension removed from the BSP. by @igorpecovnik in armbian/build#11017bsp: write the conffiles list after the hooks, and check the files are there. by @igorpecovnik in armbian/build#11008ci: enable remaining uwe related kernel modules. by @EvilOlaf in armbian/uwe5622#27cix-6.18: rebase SCMI ACPI patch onto 6.18.57. by @SuperKali in armbian/build#11016community: build orangepi4pro from the manual list. by @igorpecovnik in armbian/armbian.github.io#499download-external: fetch arch-independent debs from GitHub releases. by @SuperKali in armbian/armbian.github.io#503drop kernel configs no longer referenced. by @EvilOlaf in armbian/build#11032dut-inventory: trigger web directory rebuild after data update. by @igorpecovnik in armbian/armbian.github.io#502external: add Radxa EDK2 firmware for Qualcomm boards. by @SuperKali in armbian/os#493fix(flash): stop calling every target an SD card. by @SuperKali in armbian/imager#223Index board pinouts, schematics and instructions in armbian-images.json. by @igorpecovnik in armbian/armbian.github.io#509JetHome: Add board image for JetHub D3 (j310). by @QwaSeeK in armbian/armbian.github.io#493kickpi-k2b-v2: fix 1G Ethernet packet loss and enable 1512 MHz OPP. by @Novice-PG in armbian/build#11014mangopi-mq: boot through Debian GRUB EFI. by @khaliforce in armbian/build#10925mangopi-mq: name the board MQ Pro, add a maintainer and a test target. by @igorpecovnik in armbian/build#11001meson-s4t7: replace current (7.1) with edge (7.3), add VIM4 GPU and audio. by @igorpecovnik in armbian/build#10984meson64-7.3: aiu: keep the HDMI source bounds check. by @iav in armbian/build#10982meson64-7.3: phylink WoL: give the MAC the PHY's SecureOn password. by @iav in armbian/build#10983meson: add vdec firmware from linux-firmware. by @igorpecovnik in armbian/firmware#146mvebu: edge: Helios4 OLED via the kernel ssd130x driver. by @neheb in armbian/build#11002nightly: build Khadas VIM1S/VIM4 on edge, add GNOME mid desktop. by @igorpecovnik in armbian/armbian.github.io#498nvidia: add Tegra210 USB, GPU and VIC firmware. by @igorpecovnik in armbian/firmware#148odroidhc4: u-boot: power-cycle the SD card after a watchdog reset. by @iav in armbian/build#10992ping-unresolved-reviews: wait 48 hours before a ping. by @igorpecovnik in armbian/armbian.github.io#494Radxa Dragon Q6A: expose the SPI NOR and update firmware from armbian-install. by @SuperKali in armbian/build#11007radxa-cm5-io: u-boot: fix SPI image build. by @igorpecovnik in armbian/build#10999realtek-rtd129x: add family and BananaPi W2 with mainline kernel and u-boot. by @igorpecovnik in armbian/build#10988realtek-rtd129x: hwnat: fix RX buffer overflow on eth1. by @igorpecovnik in armbian/build#11022realtek-rtd129x: r8169soc: drop CSI access, log link changes once. by @igorpecovnik in armbian/build#11027realtek-rtd129x: watchdog: allow timeouts above the hardware limit. by @igorpecovnik in armbian/build#11023remove orphaned u-boot patches. by @EvilOlaf in armbian/build#11033Revert "drivers: net: wireless: add aic8800 sdio support". by @rpardini in armbian/linux-rockchip#587rk356x: vendor-next: make Panfrost work (OPP masks, GPU names). by @lukaszsobala in armbian/linux-rockchip#586rk35xx-vendor: enable ES8389 codec for NanoPi M6 V2. by @igorpecovnik in armbian/build#10980rockchip-6.18: fix pm-domains patch after 6.18.y update. by @igorpecovnik in armbian/build#11012rockchip-7.3: fix general-rockchip-various-fixes for 7.3-rc7. by @igorpecovnik in armbian/build#10978rockchip64-6.18: fix broken iommu driver patch. by @EvilOlaf in armbian/build#11010rockchip64-7.3: helios64: drop DTS properties that nothing reads. by @iav in armbian/build#11030rockchip64-7.3: helios64: split add-board-helios64.patch into numbered patches. by @iav in armbian/build#11004rockchip64-7.3: RK356x: suspend with USB and NVMe. by @iav in armbian/build#11005rockchip64: drop the rk_crypto2 (montjoie) crypto engine series. by @xfournet in armbian/build#10969rtd129x: add CODA980 (VE1) firmware. by @igorpecovnik in armbian/firmware#147rtl_nic: add rtl8261c.bin from linux-firmware. by @iav in armbian/firmware#145runner-cleanup: remove corrupt apt-cacher-ng by-hash entries. by @igorpecovnik in armbian/configng#1062Simplify the odroidxu4 rtl8821cu fix. by @belegdol in armbian/build#11021sophgo-sg200x: add camera support for the Milk-V Duo S J1 and J2 connectors. by @leafpmpmp in armbian/build#10936sun60iw2: install the patched Xorg only for the X11 desktops. by @igorpecovnik in armbian/build#11000sunxi-6.18: sun55i-iommu: pass old domain to attach_dev. by @EvilOlaf in armbian/build#11011sunxi-7.2: a523 HDMI audio DTS (I2S2 -> DW-HDMI, playback-only). by @juanesf in armbian/build#10913sunxi: bump edge to 7.3. by @EvilOlaf in armbian/build#11031u-boot: mainline: v2026.10 - open the floodgates. by @rpardini in armbian/build#10976u-boot: ship BOOTLOADER_BOOTS_FROM in platform_install.sh. by @SuperKali in armbian/build#11025uboot: enable EEPROM MAC sourcing for reComputer RK3576 Module Dev Kit. by @Lesords in armbian/build#10990unisocwifi: size the remaining reply buffers with sizeof (-Wvla). by @lukaszsobala in armbian/uwe5622#24Update odroidxu4-current to 6.6.159. by @belegdol in armbian/build#11013Update the ELTAY RM66 photo. by @RiPetitor in armbian/armbian.github.io#504uwe5622: bump pinned commit hash. by @EvilOlaf in armbian/build#10989uwe5622: open files from the init root on kernel 7.3. by @lukaszsobala in armbian/uwe5622#23vendor-next: Fix AIC8800 bug. by @HeyMeco in armbian/build#10977wireless: apply the RTL8821CU 6.6.157 fix only where the driver exists. by @igorpecovnik in armbian/build#11019Automatic refresh repository README. by @igorpecovnik in armbian/docker-armbian-build#41radxa-cm5-io: mainline kernel & u-boot. by @JohnTheCoolingFan in armbian/build#10979View the full article

   • October 20Oct 20
5. [Collabora] - Panfrost, Kraid, Tyr, and more at XDC 2026
   

   [Collabora] - Panfrost, Kraid, Tyr, and more at XDC 2026

   RSS Bot posted a topic in SBC News

   The annual X.Org Developer's Conference returns to Toronto September 28-30, and as a Gold Sponsor, Collabora's graphics team will present six talks and a workshop spanning Vulkan and Open Source GPU drivers. View the full article

   • September 23Sep 23
6. Efforts to develop firmware for H96 MAX V56 RK3566 8G/64G
   

   Efforts to develop firmware for H96 MAX V56 RK3566 8G/64G

   Hqnicolas posted a topic in Rockchip CPU Boxes

   🏆 Become a sponsor, help to add other boards in armbian standart, you don't need to be a programmer to help the community, just need a copy of the ARM BOARD and a x86 computer to compile new versions. If you like what you see here and want to help: Donate Armbian the like button only costs a few dollars. This Armbian adventure was summarized in my Public Github Repository. H96 MAX V56 RK3566 8gb EMMC Ning Mainline Kernel: Armbian EMMC official image Armbian Desktop Gnome kernel The Latest official Debian BookWorm Server Kernel Minimal The Latest official Software description: V0.5 = @armbian The Armbian SD card image "Compiled From Armbian Project" V0.8 = @hzdm Project with Mainline Bootloader "Boot the 64gb Emmc Armbian with Mainline Rockchip" V0.9 = @hzdm Release Mainline Bootloader "Boot the 32gb and 64gb Emmc Armbian with Mainline Rockchip" V1.0 = @hotnikq The Armbian SD card inside the Android Legacy Rockchip Image "Two Original Glued Images: Android boot for Linux" V1.2 = @ning Release Device Tree and Bootloader to longterm 6.6.27 Kernel "Boot with Mainline Rockchip" V1.3 = @Hqnicolas Github PR Enable h96 Rk3566 TV-Box device for Kernel 6.8 V1.4 = @pocosparc Github PR Enable OpenVFD and IR controller V1.5 = @dfahren Github PR Update U-boot 2025.01 for Kernel 6.12+ @fevangelou Linux Flash Tutorial @WINEDS Build Armbian for Maxios Lan Chip Board unofficial images: Edge: [Link] Desktop Resolute Server Resolute Server Trixie Current: [Link] Desktop Resolute Server Resolute Server Trixie How to Flash it: [Link] Emmc Video drivers: https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel https://docs.mesa3d.org/download.html https://docs.mesa3d.org/drivers/panfrost.html Wifi Driver: https://drive.google.com/file/d/1B1LmAylalETcnBEWiPiJHL0MjK5xlIV4/view?usp=sharing For Boards Newer than 2025: Follow @WINEDS method to compile Armbian with the ethernet and wifi drivers Front Panel Display: Tutorial Repo: https://github.com/jefflessard/tm16xx-display UEFI: https://github.com/hqnicolas/h96v56_uefi/releases/tag/v1.2.1 Or Just Live install Wifi Driver: cd /lib/firmware/brcm/ sudo wget https://github.com/CoreELEC/brcmfmac_sdio-firmware-aml/raw/master/firmware/brcm/fw_bcm4335b0_ag.bin sudo ln -s fw_bcm4335b0_ag.bin brcmfmac4335-sdio.h96-TVbox,rk3566.bin sudo reboot now nmcli dev wifi sudo rmmod brcmfmac_wcc brcmfmac brcmutil modprobe brcmfmac Topic description: This topic aims to demonstrate the path taken to the Armibian EMMC solution. In our path we create a lot of ready-to-use ROM files, some users burn an use this images without learning with the Linux compilation process. the name of the topic is efforts but that's no effort at all, you should try compile your own images. Device Capability Test: Using Rockchip SoCs NPU. Drivers: https://github.com/rockchip-linux/rknpu2 User Guide: https://github.com/rockchip-linux/rknpu2/blob/master/doc/Rockchip_RKNPU_User_Guide_RKNN_API_V1.4.0_EN.pdf OpenCV: https://opencv.org/blog/2022/11/29/working-with-neural-processing-units-npus-using-opencv/ A discussion on Reddit: https://www.reddit.com/r/OrangePI/comments/12b3jmj/accessing_the_npu_on_the_orange_pi/ Transformers models: https://github.com/usefulsensors/useful-transformers Usage: https://www.crowdsupply.com/useful-sensors/ai-in-a-box/ Usage: https://youtu.be/pN8mKZ5wpdQ

   • June 20, 20233 yr
   • 592 replies
   • 1
7. [Armbian newsletter] - Mali GPU with LiteRT-LM
   

   [Armbian newsletter] - Mali GPU with LiteRT-LM

   admin posted a topic in SBC News

   Running Gemma 4 E2B on a Mali GPU with LiteRT-LMThis guide should work on any armbian minimal/console (trixie) system with a working Mali-g610 GPU. DO NOT USE DESKTOP Verified on: Orange Pi 5 Max (Rockchip RK3588, Arm Mali-G610 MC4), Armbian/Debian 13 (trixie), aarch64, 8 GB RAM. Status summary: Both CPU (XNNPACK) and GPU (WebGPU/Dawn → Vulkan → panvk → panthor) work on the mainline panthor kernel — numbers below. The GPU path needed one line of local patching in Mesa's panvk driver (raise maxImageDimension3D 512 → 2048 to meet the WebGPU minimums that LiteRT's Dawn library enforces; recipe in §5, rationale in §7.1). The model is multimodal (Text + Vision + Audio): the vision encoder runs on the same patched panvk via--vision-backend gpu (§5 "VL path" results). The vendor Rockchip libmali route and OpenCL remain unavailable on mainline panthor (§7.2, §7.3). Stack (as shipped): Gemma 4 E2B (.litertlm, int4) → LiteRT-LM CLI → LiteRT GPU accelerator (WebGPU/ML Drift) Dawn (WebGPU impl) → Vulkan → panvk → panthor (kernel) → Mali-G610 1. PrerequisitesARM (aarch64) Linux with a Mali GPU and at least 8 GB RAM.Armbian/Debian 13 (trixie)The panthor (or panfrost for older Mali) kernel driver active:ls /dev/dri/renderD128 # render node must exist lsmod | grep panthor # or panfrost / lima Full ARMv8.2-A dotprod support is required — LiteRT's ARM64 binaries are built with it and will SIGILL otherwise:lscpu | grep -w asimddp (both A55 and A76 cores list it here). 2. Install Mesa + Vulkan for Mali (needs root)sudo apt update # Prefer the newest Mesa (backports on Debian) for the best panvk coverage of Valhall CSF GPUs: sudo apt install -y -t trixie-backports mesa-vulkan-drivers libvulkan1 vulkan-tools # Optional (see §7 — currently yields NO usable OpenCL device on panthor): sudo apt install -y -t trixie-backports mesa-opencl-icd clinfo Verify the GPU is visible to Vulkan: vulkaninfo --summary | grep -iE "deviceName|driverName" # Expect: deviceName = Mali-G610 MC4 driverName = panvk 3. Install the LiteRT-LM CLI (user space, no root)curl -LsSf https://astral.sh/uv/install.sh | sh export PATH="$HOME/.local/bin:$PATH" uv tool install litert-lm # current: v0.17.x; incl. CPU (XNNPACK/YNNPACK) + GPU (WebGPU/Vulkan) backends 4. Get the model (Gemma 4 E2B, int4 .litertlm, 2.58 GB)mkdir -p ~/litert-lm-bench && cd ~/litert-lm-bench curl -L -o gemma-4-E2B-it.litertlm \ https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm # or have the CLI fetch it for you: # litert-lm benchmark --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm gemma-4-E2B-it.litertlm Other ready models: google/gemma-3n-E2B-it-litert-lm (gemma-3n-E2B-it-int4.litertlm),litert-community/gemma-4-E4B-it-litert-lm, ... (see litert-lm list / HF). 5. BenchmarkLock the CPU governor to performance first (fair, repeatable numbers): sudo sh -c 'for c in /sys/devices/system/cpu/cpu[0-7]/cpufreq/scaling_governor; do echo performance > $c; done' CPU baseline (XNNPACK, 8 threads): litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ -p 1024 -d 256 --backend cpu --cpu-thread-count 8 --cache disk --runs 2 GPU (patched panvk, §7.1). One-time local Mesa build — stays entirely in userland, the system Mesa is untouched: # 1) Mesa source + one-line patch (26.1.2) cd ~/litert-lm-bench curl -L -o mesa.tar.xz https://archive.mesa3d.org/mesa-26.1.2.tar.xz tar -xf mesa.tar.xz && cd mesa-26.1.2 python3 - <<'PY' p = 'src/panfrost/vulkan/panvk_vX_physical_device.c' s = open(p).read() s = s.replace('.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),', '.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min */') open(p, 'w').write(s) PY # 2) build deps (the LLVM/CLC chain is required — panvk bakes CLC-compiled SPIR-V for libpan) sudo apt install -y --no-install-recommends meson ninja-build pkg-config gcc g++ python3-mako \ python3-yaml python3-ply libdrm-dev llvm-19-dev libllvmspirvlib-19-dev spirv-tools \ libclang-19-dev libclang-cpp19-dev # 3) panvk-only build (~10–25 min on the 5 Max) meson setup build-panvk -Dvulkan-drivers=panfrost -Dgallium-drivers= -Dbuildtype=release \ -Dllvm=enabled -Dmesa-clc=auto -Dplatforms= -Degl=disabled -Dgbm=disabled -Dglx=disabled \ -Dopengl=false -Dglvnd=disabled -Dtools= -Dbuild-tests=false ninja -C build-panvk -j6 # 4) benchmark with the patched driver, process-scoped. First put the WebGPU prebuilts # (libLiteRtTopKWebGpuSampler.so + libwebgpu_dawn.so etc., litert-lm repo tag v0.17.1, # prebuilt/linux_arm64) in ~/litert-lm-bench/prebuilt_v0171/ — see Troubleshooting. export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json" export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171" export PATH="$HOME/.local/bin:$PATH" # uv-installed CLI litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ -p 1024 -d 256 --backend gpu --cache disk --runs 2 First GPU run compiles the WebGPU/Vulkan shaders (one-time) and uploads GPU-rearranged weights (~0.8 GB weight cache); --cache disk persists both next to the model, so later loads start fast — the compile cost is NOT repaid on every run. Results on this Orange Pi 5 Max (Mali-G610 MC4) Backend Prefill (tk/s) Decode (tk/s) TTFT (s) CPU (XNNPACK, 8 threads) 123.6 12.3 8.4 GPU (WebGPU/Dawn→Vulkan, patched panvk §5/§7.1) 374.0 8.7 2.9 Google's on-device-class references for Gemma 4 E2B: S26 Ultra GPU 3808/52 tk/s, Raspberry Pi 5 CPU 133/7.6 tk/s. On this board the GPU wins the prefill race by ~3.0× (374 vs 124 tk/s) and TTFT by ~2.9× (2.9 vs 8.4 s), while decode stays on the CPU's side (8.7 vs 12.3 tk/s) — as expected, decode is the bottleneck on Mali-class hardware; the Mali GPU is a prefill/TTFT accelerator here, not a decode accelerator. GPU clock note (measured, no guesswork): the Mali-G610 is an integrated GPU sharing the board's DDR. The devfreq governor (simple_ondemand, stock) boosts it to 1 GHz under load and parks it at 200 MHz idle — confirmed by sampling cur_freq at 400 ms during the run (233/263 samples at 1000 MHz, temps 41→56 °C, no thermal trip). Leave the governor alone: forcingperformance/min/max via sysfs was counterproductive (idle readbacks that look like the clock collapsed, and it destabilized perfectly good runs). The numbers above are at the stock governor's real 1 GHz boost. Results: Gemma 4 E4B (4B) — text GPU via the web flavor, vision GPU straight from stockE4B (the 4B sibling) ships as three files in the HF repo: the stock gemma-4-E4B-it.litertlm (text+vision+audio, 3.66 GB) plus an -gpu and a -web (text-only, 2.97 GB) variant. On this 8 GB board the stock file cannot run on the GPU — two structural walls, both measured: panthor job watchdog: a fixed one-shot pipeline dispatch (dmesg: job timeout ... seqno=144, same job on every E4B attempt) exceeds the driver's compiled-in 1 s job timeout even at the real 1 GHz boost (E2B's equivalent is seqno=77 and fits). The GPU is reset, Dawn reports VK_ERROR_DEVICE_LOST, generation aborts. 8 GB RAM ceiling: GPU buffers (pinned, unrescalable shmem) peak near 4–5 GB on top of the 3.66 GB model; every run ended in a global OOM-kill (EXIT=137) during iteration 2 even with a 2048-token KV cap + ringbuffers + disk cache. The -web flavor dodges both — its finer op layout splits the killer dispatch under the 1 s bar and shrinks the GPU working set (peak 4.3 GB observed, holds 1 GHz the whole run): Gemma 4 E4B lane Flavor Prefill (tk/s) Decode (tk/s) TTFT (s) CPU (XNNPACK, 8 threads) stock 52.6 5.58 19.6 GPU (patched panvk) web (text-only) 75.1 4.54 13.9 (reproducible to the decimal across --runs 2; init 6.2 s; note --cache disk does not persist for the web flavor — expect a recompile each run. --speculative-decoding true gave no gain:4.37 vs 4.54 tok/s decode (this build ships no draft model).) Reference: Raspberry Pi 5 (16 GB, CPU) 51/3.2/20.5 — this board matches or beats it on every column. Same shape as E2B: GPU wins prefill +1.4× and TTFT 19.6→13.9 s, but decode stays CPU-favored (4.5 vs 5.6 tk/s). E4B vision (VL) on GPU works — cpu text + gpu visionThe stock E4B's vision encoder is a separate 1477-op subgraph that fits under the panthor watchdog and inside 8 GB even though the full stock model's text lane does not. Drive it via the Engine API (this repo's vl_bench.py --model ...), LLM lane = CPU, vision encoder = GPU (patched panvk): the test image (resized to 912×672 → 2394 patches, near E4B's max_num_patches 2520) is encoded on the Mali. E4B VL (LLM lane = cpu) vision cpu vision gpu (patched panvk) TTFT (s) 12.3–12.5 9.6 Decode (tok/s) 7.33–7.37 7.28–7.39 Reply (same image) "coyote walking on a dirt path" identical Text-only CPU control: TTFT ≈ 2.0 s (7-token prompt, decode ~7.8 tok/s). Isolated vision-encode cost: ~10.4 s CPU vs ~7.6 s GPU — the Mali cuts E4B vision latency by ~2.9 s/image (~27%). No watchdog hits, no OOM (peaks well below ceiling; vision weights are a fraction of a GB). Same conclusion as E2B: for vision work keep the LLM on CPU and let the GPU run the encoder. # 1. SET ENVIRONMENT FOR GPU VISION DELEGATE export LITERT_VISION_DELEGATE=gpu # 2. RUN VL HARNESS FOR STOCK GEMMA-4-E4B ~/.local/share/uv/tools/litert-lm/bin/python vl_bench.py \ --text cpu \ --vision gpu \ --image \ --iters 3 \ --model gemma-4-E4B-it.litertlm# Ensure directory exists and download model mkdir -p ~/litert-lm-bench curl -L -o ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \ https://huggingface.co/litert-community/gemma-4-E4B-it-litert-lm/resolve/main/gemma-4-E4B-it-web.litertlm # Execute benchmark with standard LiteRT-LM flags litert-lm benchmark ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \ --backend=gpu \ -p 1024 \ -d 256 \ --runs 2Results: VL (vision) pathThe benchmark sub-command only benches the text path. To time the vision encoder, drive the same engine via the Python API (vl_bench.py in this directory) — it loads the model, streams a real image (test_multi.jpg, httpbin.org/image/jpeg) + text through vision_backend=cpu|gpu and prints TTFT (vision encode + prefill + first token), per-chunk decode rate, and the reply. One sentence prompt, 13-token answer, ~290-token total prefill (280 vision + text), generations deterministic (temperature=0). Medians over 3+ runs after compile: Combo (text / vision) VL TTFT (s) Decode (tok/s) Reply matches CPU? cpu / cpu 8.93–9.40 17.4 baseline cpu / gpu (patched panvk) 6.16–6.62 17.2 yes, identical gpu / gpu (patched panvk) 5.62–6.16 9.8 yes, identical Text-only controls (7-token prompt): CPU TTFT ≈ 0.8 s, GPU TTFT ≈ 0.57 s. Isolating the vision cost (VL TTFT − text-only TTFT for the same text backend): ~8.1 s on a CPU vision encoder vs ~5.4 s GPU — the Mali GPU cuts vision-encoder latency by ~2.7–3 s per image (~30%), and the full-GPU combo is ~37% faster end-to-end (5.6 vs 8.9 s). The patched panvk covers the model's separate VISION_ENCODER subgraph too (no extra Dawn limits tripped). Caveat: for short generations (< ~20 tokens) GPU decode is slower than CPU (9.8 vs 17.4 tok/s) — per-iteration GPU sync overhead — so for chatty/VL replies the CPU text lane with GPU vision is often the best mix (6.2 s TTFT, CPU-fast decode). Benchmarking the VL path yourself# 1. FETCH SAMPLE TEST IMAGE curl -sL -o ~/litert-lm-bench/test_multi.jpg https://httpbin.org/image/jpeg # 2. SET PYTHON INTERPRETER PATH VL_PY=~/.local/share/uv/tools/litert-lm/bin/python # 3. BASELINE: TEXT (CPU) + VISION (CPU) $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision cpu --image --iters 3 # 4. HYBRID: TEXT (CPU) + VISION (GPU) — EXPORT PANVK MESA ENVS FIRST export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json" export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171" $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision gpu --image --iters 3 # 5. FULL ACCELERATION: TEXT (GPU) + VISION (GPU) $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --vision gpu --image --iters 3 # 6. TEXT-ONLY CONTROLS (ISOLATE VISION-ENCODER COST) $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --iters 3 $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --iters 3 Prints per-iteration TTFT / decode tok/s / reply. Run cases sequentially — parallel GPU runs contend for the Mali GPU and inflate the numbers (observed 2× TTFT when two ran at once). 6. Inference# 1. DIRECT CLI EVALUATION litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ --cache disk --prompt "What is the capital of France?" # 2. INTERACTIVE REPL MODE litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm # 3. OPENAI-COMPATIBLE API SERVER litert-lm serve ~/litert-lm-bench/gemma-4-E2B-it.litertlm Vision (and audio) input uses run with attachments — one per --attachment, placed before the first user text (images and audio can be mixed): litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ --attachment ~/litert-lm-bench/test_multi.jpg \ --prompt "What is in this image? Answer in one sentence." \ --vision-backend cpu # or gpu (patched panvk, §5) — ~2.7–3 s faster vision encode --vision-backend/--audio-backend pick the encoder lane independently of --backend (which chooses the LLM lane). Like --backend gpu, --vision-backend gpu needs the §5 env (VK_ICD_FILENAMES + LD_LIBRARY_PATH) exported for that run. Notes: --cache disk persists compiled artifacts next to the model — the first GPU load compiles shaders, later loads start instantly. The load time is NOT paid on every run. Observed caches: <model>_*_mldrift_program_cache.bin (compiled kernels) and<model>_*_mldrift_weight_cache.bin (GPU-rearranged weights, ~0.8 GB). The vision encoder's kernels live in the same cache files — first GPU --vision-backend gpu run compiles, later runs reuse. GPU (patched panvk) is ~2.8× faster at prefill and ~2.7× on TTFT, but ~30% slower at decode — pick the lane by workload (§7.4). Vision: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s per image; CPU text + GPU vision is the best blend for short/chatty replies (§5 VL results). Speculative decoding (--speculative-decoding true) can lift decode on CPU+GPU for rewrite/summarize/coding style prompts (Gemma 4 E2B supports it). 7. GPU deep dive: the blocker and how it was unblocked hereEverything below was reproduced with LiteRT-LM v0.17.1 (CLI + litert-lm-api), Mesa 26.1.2 (trixie-backports), kernel 7.2.4-edge-rockchip64 (mainline panthor). 7.1 The panvk limit blocker — RESOLVED with a one-line local patchLiteRT's WebGPU accelerator uses Dawn, which enforces the WebGPU spec minimums against the Vulkan driver and refuses to proceed when they are unmet. Stock panvk reports: maxImageDimension3D = 512 # WebGPU spec requires ≥ 2048 Dawn logs exactly this (PhysicalDeviceVk.cpp:794: "Insufficient Vulkan limits for maxTextureDimension3D ... must be at least 2048"), and stock panvk then dies with a null-pointer dispatch (SIGSEGV, pc=0x0) inside the WebGPU path on the first real GPU execution. The root cause is the driver limit, not packaging: the crash is identical even with the WebGPU prebuilts (libLiteRtTopKWebGpuSampler.so + friends) fetched from the litert-lm repo prebuilt/linux_arm64 @ v0.17.1 on LD_LIBRARY_PATH. The fix (validated on this board): panvk caps 3D textures at 512 for Valhall (PAN_ARCH <= 10), but the Mali-G610 hardware handles 2048³ — raising the advertised limit to 2048 makes Dawn accept the adapter: -.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14), +.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min (was 512 on arch <= 10) */ Why it's safe: Dawn only validates the advertised limit against its spec minimum, and the value also caps future image allocations — so if a kernel ever genuinely requested a 2048³ 3D texture, panvk would fail cleanly at allocation instead of corrupting anything. LiteRT/ML-Drift's LLM and vision-encoder kernels allocate buffers and 2D textures only, so real GPU behaviour is unchanged; Dawn simply stops rejecting the adapter, the SIGSEGV disappears, and the full benchmark runs (§5). Confirmed via vulkaninfo on the patched build: maxImageDimension3D = 2048. All other WebGPU minimums (per-stage descriptors, workgroup sizes, buffer ranges) were already comfortably met. The build is process-scoped (VK_ICD_FILENAMES + LD_LIBRARY_PATH per run), the system Mesa is never touched, and reverting is unsetting two variables. Unless/until Mesa raises this limit upstream for Valhall, keep this build around for LiteRT-LM GPU runs. 7.2 The vendor route (Rockchip libmali) — needs a different kernelRockchip's proprietary blob would satisfy Dawn (it exposes Vulkan 1.3 with full limits), but the blob's userspace talks to Rockchip's proprietary kbase kernel driver (/dev/mali) and cannot attach to the mainline panthor driver: "libmali-valhall-g610-g13p0-gbm" → loads, exports NO Vulkan ICD (0 vk_* symbols) "libmali-valhall-g610-g24p0-gbm" libMaliVulkan.so.1 (api 1.3.276) → loads, "No mali devices found" then SIGSEGV (no /dev/mali) Installable packages exist (tsukumijima/libmali-rockchip releases, e.g. v1.9-1-20260312-bd33ee2), but they all presume the vendor kernel. Unblock: flash a vendor-kernel image (kernel with kbase/mali.ko, e.g. Armbian images with the Rockchip BSP kernel), then install libmali-valhall-g610-g13p0-gbm (or g24p0) and point Dawn/Vulkan at it (VK_DRIVER_FILES/LD_LIBRARY_PATH). That same blob also provides OpenCL 3.0 (libMaliOpenCL.so + /etc/OpenCL/vendors/mali.icd), which would additionally satisfy the "would OpenCL be faster?" curiosity — for running LLMs, both WebGPU/Vulkan and OpenCL on the same GPU land in the same class of throughput; the win is the mature compiler's fast startup, not raw speed. 7.3 OpenCL on the current kernel — not availableMesa's rusticl on panthor currently exposes zero devices (clinfo -l shows only the rusticl platform, no device). So there is no OpenCL device at all on the mainline stack, and LiteRT-LM has no Linux OpenCL accelerator anyway. 7.4 Practical advice for this board todayChat / streaming (decode-bound): CPU is the better lane — 12.3 vs 8.7 tk/s decode.Long prompts / RAG / document Q&A (prefill-bound): GPU pays off — 345 vs 124 tk/s prefill, 3.1 vs 8.4 s TTFT.Images / VL: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s (~30%). Shortest VL TTFT is text+vision both on GPU (5.6 vs 8.9 s all-CPU), but keep the LLM on CPU when replies are short and chatty (6.2 s TTFT plus CPU-fast decode). --speculative-decoding true can lift decode further on both lanes (Gemma 4 E2B supports it).Serving an OpenAI-compatible endpoint (litert-lm serve)litert-lm serve exposes an OpenAI API on 0.0.0.0:9379, so LAN clients (LiteCode, opencode, aider, Continue, scripts) use the board like any OpenAI endpoint. Import a model once (litert-lm import ./gemma-4-E2B-it.litertlm, registry at ~/.litert-lm/models/), then litert-lm serve. Per-model settings come from ~/.litert-lm/config.json (default + models.<id>), so clients stay plain-OpenAI: { "default": { "backend": "cpu", "cpu_thread_count": 8, "cache": "disk" }, "models": { "gemma-4-E2B-it.litertlm": { "speculative_decoding": true, "max_num_tokens": 4096 } } } Endpoints: GET /v1/models and POST /v1/chat/completions (streaming + non-streaming). OpenAI tools / tool_choice are bridged to the model's function-calling template — verified to return valid tool_calls JSON (non-streaming and streamed) and to complete the full agent cycle (assistant tool_call → tool result → final answer). /v1/embeddings exists but is not tied to LLM models. Even though litert-lm describe reports Supports Function Call: NO for Gemma 4, the serve layer still bridges tools into the model template (empirically verified); that flag only means the CLI's interactive run has no native FC template. RAM budget (E2B, CPU): max_num_tokens preallocates KV/ringbuffer arenas up front.Measured process RSS: 4096 → ~3.1 GB (4.9 GB free — recommended), 8192 → ~7 GB (1.1 GB free — works but leaves no headroom). Keep 4096 and let clients budget. Config keys (0.15+): backend, vision_backend, audio_backend, cpu_thread_count, cache, max_num_tokens, speculative_decoding, thinking, thinking_budget, gpu_decode_steps_per_sync, sampling. CLI flags override config. For a persistent border, run under systemd. Verified client on this boardLiteCode (razvanneculai/litecode) — works end-to-end. Its Planner ({"synthesis","tasks"} strict JSON) and Executor (raw file content, no fences) prompts fit the 4096 budget; single-request task runs completed correctly and files linter-clean. litecode.json: { "provider": { "baseURL": "http://<yourIP>:9379/v1", "apiKey": "", "model": "gemma-4-E2B-it.litertlm" }, "tokenLimit": 4096, "reservedOutputTokens": 1500, "systemPromptBudget": 1000, "maxParallelExecutors": 1 } TroubleshootingFATAL ERROR: This binary was compiled with dotprod enabled... → CPU lacks FEAT_DotProd, not supported by the ARM64 prebuilt wheels. RK3588 has it. GPU benchmark errors but CPU works → with stock Mesa this is the §7.1 Dawn limit crash (maxImageDimension3D = 512); with the patched build, check vulkaninfo --summary again — panvk must list the Mali device and report maxImageDimension3D = 2048. ExportVK_ICD_FILENAMES+LD_LIBRARY_PATH for every run that should use the patched driver. Could not load shared library libLiteRtTopKWebGpuSampler.so → the CLI wheel does not bundle the WebGPU samplers; fetch them from the litert-lm repo prebuilt/linux_arm64/ at the matching version tag (e.g. v0.17.1) and export their directory on LD_LIBRARY_PATH. First GPU run is slow (one-time kernel compilation) — normal; use --cache disk so later loads skip it. Caches persist next to the model. Bigger models (e.g. stock gemma-4-E4B-it.litertlm, 3.66 GB) fail on the GPU even with the patched driver: panthor ... job timeout in dmesg (fixed 1 s driver watchdog, not tunable; the model has a one-shot dispatch that exceeds it even at the real 1 GHz boost) theVK_ERROR_DEVICE_LOST, and/or a global OOM-kill (EXIT=137) when pinned GPU buffers + the model outgrow 8 GB. E2B fits, E4B-stock doesn't. Use the text-only -web flavor (gemma-4-E4B-it-web.litertlm, 2.97 GB) for E4B-on-GPU — its finer kernels stay under the watchdog and its GPU set peaks ~4.3 GB (§5 E4B section). Join the conversation on the Armbian Forum and let us know how it runs on your hardware! View the full article

   • September 30Sep 30
8. [News from Armbian] - Mali GPU with LiteRT-LM
   

   [News from Armbian] - Mali GPU with LiteRT-LM

   RSS Bot posted a topic in SBC News

   Running Gemma 4 E2B on a Mali GPU with LiteRT-LMThis guide should work on any armbian minimal/console (trixie) system with a working Mali-g610 GPU. DO NOT USE DESKTOP Verified on: Orange Pi 5 Max (Rockchip RK3588, Arm Mali-G610 MC4), Armbian/Debian 13 (trixie), aarch64, 8 GB RAM. Status summary: Both CPU (XNNPACK) and GPU (WebGPU/Dawn → Vulkan → panvk → panthor) work on the mainline panthor kernel — numbers below. The GPU path needed one line of local patching in Mesa's panvk driver (raise maxImageDimension3D 512 → 2048 to meet the WebGPU minimums that LiteRT's Dawn library enforces; recipe in §5, rationale in §7.1). The model is multimodal (Text + Vision + Audio): the vision encoder runs on the same patched panvk via--vision-backend gpu (§5 "VL path" results). The vendor Rockchip libmali route and OpenCL remain unavailable on mainline panthor (§7.2, §7.3). Stack (as shipped): Gemma 4 E2B (.litertlm, int4) → LiteRT-LM CLI → LiteRT GPU accelerator (WebGPU/ML Drift) Dawn (WebGPU impl) → Vulkan → panvk → panthor (kernel) → Mali-G610 1. PrerequisitesARM (aarch64) Linux with a Mali GPU and at least 8 GB RAM.Armbian/Debian 13 (trixie)The panthor (or panfrost for older Mali) kernel driver active:ls /dev/dri/renderD128 # render node must exist lsmod | grep panthor # or panfrost / lima Full ARMv8.2-A dotprod support is required — LiteRT's ARM64 binaries are built with it and will SIGILL otherwise:lscpu | grep -w asimddp (both A55 and A76 cores list it here). 2. Install Mesa + Vulkan for Mali (needs root)sudo apt update # Prefer the newest Mesa (backports on Debian) for the best panvk coverage of Valhall CSF GPUs: sudo apt install -y -t trixie-backports mesa-vulkan-drivers libvulkan1 vulkan-tools # Optional (see §7 — currently yields NO usable OpenCL device on panthor): sudo apt install -y -t trixie-backports mesa-opencl-icd clinfo Verify the GPU is visible to Vulkan: vulkaninfo --summary | grep -iE "deviceName|driverName" # Expect: deviceName = Mali-G610 MC4 driverName = panvk 3. Install the LiteRT-LM CLI (user space, no root)curl -LsSf https://astral.sh/uv/install.sh | sh export PATH="$HOME/.local/bin:$PATH" uv tool install litert-lm # current: v0.17.x; incl. CPU (XNNPACK/YNNPACK) + GPU (WebGPU/Vulkan) backends 4. Get the model (Gemma 4 E2B, int4 .litertlm, 2.58 GB)mkdir -p ~/litert-lm-bench && cd ~/litert-lm-bench curl -L -o gemma-4-E2B-it.litertlm \ https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm # or have the CLI fetch it for you: # litert-lm benchmark --from-huggingface-repo litert-community/gemma-4-E2B-it-litert-lm gemma-4-E2B-it.litertlm Other ready models: google/gemma-3n-E2B-it-litert-lm (gemma-3n-E2B-it-int4.litertlm),litert-community/gemma-4-E4B-it-litert-lm, ... (see litert-lm list / HF). 5. BenchmarkLock the CPU governor to performance first (fair, repeatable numbers): sudo sh -c 'for c in /sys/devices/system/cpu/cpu[0-7]/cpufreq/scaling_governor; do echo performance > $c; done' CPU baseline (XNNPACK, 8 threads): litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ -p 1024 -d 256 --backend cpu --cpu-thread-count 8 --cache disk --runs 2 GPU (patched panvk, §7.1). One-time local Mesa build — stays entirely in userland, the system Mesa is untouched: # 1) Mesa source + one-line patch (26.1.2) cd ~/litert-lm-bench curl -L -o mesa.tar.xz https://archive.mesa3d.org/mesa-26.1.2.tar.xz tar -xf mesa.tar.xz && cd mesa-26.1.2 python3 - <<'PY' p = 'src/panfrost/vulkan/panvk_vX_physical_device.c' s = open(p).read() s = s.replace('.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),', '.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min */') open(p, 'w').write(s) PY # 2) build deps (the LLVM/CLC chain is required — panvk bakes CLC-compiled SPIR-V for libpan) sudo apt install -y --no-install-recommends meson ninja-build pkg-config gcc g++ python3-mako \ python3-yaml python3-ply libdrm-dev llvm-19-dev libllvmspirvlib-19-dev spirv-tools \ libclang-19-dev libclang-cpp19-dev # 3) panvk-only build (~10–25 min on the 5 Max) meson setup build-panvk -Dvulkan-drivers=panfrost -Dgallium-drivers= -Dbuildtype=release \ -Dllvm=enabled -Dmesa-clc=auto -Dplatforms= -Degl=disabled -Dgbm=disabled -Dglx=disabled \ -Dopengl=false -Dglvnd=disabled -Dtools= -Dbuild-tests=false ninja -C build-panvk -j6 # 4) benchmark with the patched driver, process-scoped. First put the WebGPU prebuilts # (libLiteRtTopKWebGpuSampler.so + libwebgpu_dawn.so etc., litert-lm repo tag v0.17.1, # prebuilt/linux_arm64) in ~/litert-lm-bench/prebuilt_v0171/ — see Troubleshooting. export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json" export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171" export PATH="$HOME/.local/bin:$PATH" # uv-installed CLI litert-lm benchmark ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ -p 1024 -d 256 --backend gpu --cache disk --runs 2 First GPU run compiles the WebGPU/Vulkan shaders (one-time) and uploads GPU-rearranged weights (~0.8 GB weight cache); --cache disk persists both next to the model, so later loads start fast — the compile cost is NOT repaid on every run. Results on this Orange Pi 5 Max (Mali-G610 MC4) Backend Prefill (tk/s) Decode (tk/s) TTFT (s) CPU (XNNPACK, 8 threads) 123.6 12.3 8.4 GPU (WebGPU/Dawn→Vulkan, patched panvk §5/§7.1) 374.0 8.7 2.9 Google's on-device-class references for Gemma 4 E2B: S26 Ultra GPU 3808/52 tk/s, Raspberry Pi 5 CPU 133/7.6 tk/s. On this board the GPU wins the prefill race by ~3.0× (374 vs 124 tk/s) and TTFT by ~2.9× (2.9 vs 8.4 s), while decode stays on the CPU's side (8.7 vs 12.3 tk/s) — as expected, decode is the bottleneck on Mali-class hardware; the Mali GPU is a prefill/TTFT accelerator here, not a decode accelerator. GPU clock note (measured, no guesswork): the Mali-G610 is an integrated GPU sharing the board's DDR. The devfreq governor (simple_ondemand, stock) boosts it to 1 GHz under load and parks it at 200 MHz idle — confirmed by sampling cur_freq at 400 ms during the run (233/263 samples at 1000 MHz, temps 41→56 °C, no thermal trip). Leave the governor alone: forcingperformance/min/max via sysfs was counterproductive (idle readbacks that look like the clock collapsed, and it destabilized perfectly good runs). The numbers above are at the stock governor's real 1 GHz boost. Results: Gemma 4 E4B (4B) — text GPU via the web flavor, vision GPU straight from stockE4B (the 4B sibling) ships as three files in the HF repo: the stock gemma-4-E4B-it.litertlm (text+vision+audio, 3.66 GB) plus an -gpu and a -web (text-only, 2.97 GB) variant. On this 8 GB board the stock file cannot run on the GPU — two structural walls, both measured: panthor job watchdog: a fixed one-shot pipeline dispatch (dmesg: job timeout ... seqno=144, same job on every E4B attempt) exceeds the driver's compiled-in 1 s job timeout even at the real 1 GHz boost (E2B's equivalent is seqno=77 and fits). The GPU is reset, Dawn reports VK_ERROR_DEVICE_LOST, generation aborts. 8 GB RAM ceiling: GPU buffers (pinned, unrescalable shmem) peak near 4–5 GB on top of the 3.66 GB model; every run ended in a global OOM-kill (EXIT=137) during iteration 2 even with a 2048-token KV cap + ringbuffers + disk cache. The -web flavor dodges both — its finer op layout splits the killer dispatch under the 1 s bar and shrinks the GPU working set (peak 4.3 GB observed, holds 1 GHz the whole run): Gemma 4 E4B lane Flavor Prefill (tk/s) Decode (tk/s) TTFT (s) CPU (XNNPACK, 8 threads) stock 52.6 5.58 19.6 GPU (patched panvk) web (text-only) 75.1 4.54 13.9 (reproducible to the decimal across --runs 2; init 6.2 s; note --cache disk does not persist for the web flavor — expect a recompile each run. --speculative-decoding true gave no gain:4.37 vs 4.54 tok/s decode (this build ships no draft model).) Reference: Raspberry Pi 5 (16 GB, CPU) 51/3.2/20.5 — this board matches or beats it on every column. Same shape as E2B: GPU wins prefill +1.4× and TTFT 19.6→13.9 s, but decode stays CPU-favored (4.5 vs 5.6 tk/s). E4B vision (VL) on GPU works — cpu text + gpu visionThe stock E4B's vision encoder is a separate 1477-op subgraph that fits under the panthor watchdog and inside 8 GB even though the full stock model's text lane does not. Drive it via the Engine API (this repo's vl_bench.py --model ...), LLM lane = CPU, vision encoder = GPU (patched panvk): the test image (resized to 912×672 → 2394 patches, near E4B's max_num_patches 2520) is encoded on the Mali. E4B VL (LLM lane = cpu) vision cpu vision gpu (patched panvk) TTFT (s) 12.3–12.5 9.6 Decode (tok/s) 7.33–7.37 7.28–7.39 Reply (same image) "coyote walking on a dirt path" identical Text-only CPU control: TTFT ≈ 2.0 s (7-token prompt, decode ~7.8 tok/s). Isolated vision-encode cost: ~10.4 s CPU vs ~7.6 s GPU — the Mali cuts E4B vision latency by ~2.9 s/image (~27%). No watchdog hits, no OOM (peaks well below ceiling; vision weights are a fraction of a GB). Same conclusion as E2B: for vision work keep the LLM on CPU and let the GPU run the encoder. # 1. SET ENVIRONMENT FOR GPU VISION DELEGATE export LITERT_VISION_DELEGATE=gpu # 2. RUN VL HARNESS FOR STOCK GEMMA-4-E4B ~/.local/share/uv/tools/litert-lm/bin/python vl_bench.py \ --text cpu \ --vision gpu \ --image \ --iters 3 \ --model gemma-4-E4B-it.litertlm# Ensure directory exists and download model mkdir -p ~/litert-lm-bench curl -L -o ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \ https://huggingface.co/litert-community/gemma-4-E4B-it-litert-lm/resolve/main/gemma-4-E4B-it-web.litertlm # Execute benchmark with standard LiteRT-LM flags litert-lm benchmark ~/litert-lm-bench/gemma-4-E4B-it-web.litertlm \ --backend=gpu \ -p 1024 \ -d 256 \ --runs 2Results: VL (vision) pathThe benchmark sub-command only benches the text path. To time the vision encoder, drive the same engine via the Python API (vl_bench.py in this directory) — it loads the model, streams a real image (test_multi.jpg, httpbin.org/image/jpeg) + text through vision_backend=cpu|gpu and prints TTFT (vision encode + prefill + first token), per-chunk decode rate, and the reply. One sentence prompt, 13-token answer, ~290-token total prefill (280 vision + text), generations deterministic (temperature=0). Medians over 3+ runs after compile: Combo (text / vision) VL TTFT (s) Decode (tok/s) Reply matches CPU? cpu / cpu 8.93–9.40 17.4 baseline cpu / gpu (patched panvk) 6.16–6.62 17.2 yes, identical gpu / gpu (patched panvk) 5.62–6.16 9.8 yes, identical Text-only controls (7-token prompt): CPU TTFT ≈ 0.8 s, GPU TTFT ≈ 0.57 s. Isolating the vision cost (VL TTFT − text-only TTFT for the same text backend): ~8.1 s on a CPU vision encoder vs ~5.4 s GPU — the Mali GPU cuts vision-encoder latency by ~2.7–3 s per image (~30%), and the full-GPU combo is ~37% faster end-to-end (5.6 vs 8.9 s). The patched panvk covers the model's separate VISION_ENCODER subgraph too (no extra Dawn limits tripped). Caveat: for short generations (< ~20 tokens) GPU decode is slower than CPU (9.8 vs 17.4 tok/s) — per-iteration GPU sync overhead — so for chatty/VL replies the CPU text lane with GPU vision is often the best mix (6.2 s TTFT, CPU-fast decode). Benchmarking the VL path yourself# 1. FETCH SAMPLE TEST IMAGE curl -sL -o ~/litert-lm-bench/test_multi.jpg https://httpbin.org/image/jpeg # 2. SET PYTHON INTERPRETER PATH VL_PY=~/.local/share/uv/tools/litert-lm/bin/python # 3. BASELINE: TEXT (CPU) + VISION (CPU) $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision cpu --image --iters 3 # 4. HYBRID: TEXT (CPU) + VISION (GPU) — EXPORT PANVK MESA ENVS FIRST export BUILD=~/litert-lm-bench/mesa-26.1.2/build-panvk export VK_ICD_FILENAMES="$BUILD/src/panfrost/vulkan/panfrost_devenv_icd.aarch64.json" export LD_LIBRARY_PATH="$BUILD/src/panfrost/vulkan:$HOME/litert-lm-bench/prebuilt_v0171" $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --vision gpu --image --iters 3 # 5. FULL ACCELERATION: TEXT (GPU) + VISION (GPU) $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --vision gpu --image --iters 3 # 6. TEXT-ONLY CONTROLS (ISOLATE VISION-ENCODER COST) $VL_PY ~/litert-lm-bench/vl_bench.py --text cpu --iters 3 $VL_PY ~/litert-lm-bench/vl_bench.py --text gpu --iters 3 Prints per-iteration TTFT / decode tok/s / reply. Run cases sequentially — parallel GPU runs contend for the Mali GPU and inflate the numbers (observed 2× TTFT when two ran at once). 6. Inference# 1. DIRECT CLI EVALUATION litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ --cache disk --prompt "What is the capital of France?" # 2. INTERACTIVE REPL MODE litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm # 3. OPENAI-COMPATIBLE API SERVER litert-lm serve ~/litert-lm-bench/gemma-4-E2B-it.litertlm Vision (and audio) input uses run with attachments — one per --attachment, placed before the first user text (images and audio can be mixed): litert-lm run ~/litert-lm-bench/gemma-4-E2B-it.litertlm \ --attachment ~/litert-lm-bench/test_multi.jpg \ --prompt "What is in this image? Answer in one sentence." \ --vision-backend cpu # or gpu (patched panvk, §5) — ~2.7–3 s faster vision encode --vision-backend/--audio-backend pick the encoder lane independently of --backend (which chooses the LLM lane). Like --backend gpu, --vision-backend gpu needs the §5 env (VK_ICD_FILENAMES + LD_LIBRARY_PATH) exported for that run. Notes: --cache disk persists compiled artifacts next to the model — the first GPU load compiles shaders, later loads start instantly. The load time is NOT paid on every run. Observed caches: <model>_*_mldrift_program_cache.bin (compiled kernels) and<model>_*_mldrift_weight_cache.bin (GPU-rearranged weights, ~0.8 GB). The vision encoder's kernels live in the same cache files — first GPU --vision-backend gpu run compiles, later runs reuse. GPU (patched panvk) is ~2.8× faster at prefill and ~2.7× on TTFT, but ~30% slower at decode — pick the lane by workload (§7.4). Vision: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s per image; CPU text + GPU vision is the best blend for short/chatty replies (§5 VL results). Speculative decoding (--speculative-decoding true) can lift decode on CPU+GPU for rewrite/summarize/coding style prompts (Gemma 4 E2B supports it). 7. GPU deep dive: the blocker and how it was unblocked hereEverything below was reproduced with LiteRT-LM v0.17.1 (CLI + litert-lm-api), Mesa 26.1.2 (trixie-backports), kernel 7.2.4-edge-rockchip64 (mainline panthor). 7.1 The panvk limit blocker — RESOLVED with a one-line local patchLiteRT's WebGPU accelerator uses Dawn, which enforces the WebGPU spec minimums against the Vulkan driver and refuses to proceed when they are unmet. Stock panvk reports: maxImageDimension3D = 512 # WebGPU spec requires ≥ 2048 Dawn logs exactly this (PhysicalDeviceVk.cpp:794: "Insufficient Vulkan limits for maxTextureDimension3D ... must be at least 2048"), and stock panvk then dies with a null-pointer dispatch (SIGSEGV, pc=0x0) inside the WebGPU path on the first real GPU execution. The root cause is the driver limit, not packaging: the crash is identical even with the WebGPU prebuilts (libLiteRtTopKWebGpuSampler.so + friends) fetched from the litert-lm repo prebuilt/linux_arm64 @ v0.17.1 on LD_LIBRARY_PATH. The fix (validated on this board): panvk caps 3D textures at 512 for Valhall (PAN_ARCH <= 10), but the Mali-G610 hardware handles 2048³ — raising the advertised limit to 2048 makes Dawn accept the adapter: -.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14), +.maxImageDimension3D = (1 << 11), /* 2048 — meets WebGPU min (was 512 on arch <= 10) */ Why it's safe: Dawn only validates the advertised limit against its spec minimum, and the value also caps future image allocations — so if a kernel ever genuinely requested a 2048³ 3D texture, panvk would fail cleanly at allocation instead of corrupting anything. LiteRT/ML-Drift's LLM and vision-encoder kernels allocate buffers and 2D textures only, so real GPU behaviour is unchanged; Dawn simply stops rejecting the adapter, the SIGSEGV disappears, and the full benchmark runs (§5). Confirmed via vulkaninfo on the patched build: maxImageDimension3D = 2048. All other WebGPU minimums (per-stage descriptors, workgroup sizes, buffer ranges) were already comfortably met. The build is process-scoped (VK_ICD_FILENAMES + LD_LIBRARY_PATH per run), the system Mesa is never touched, and reverting is unsetting two variables. Unless/until Mesa raises this limit upstream for Valhall, keep this build around for LiteRT-LM GPU runs. 7.2 The vendor route (Rockchip libmali) — needs a different kernelRockchip's proprietary blob would satisfy Dawn (it exposes Vulkan 1.3 with full limits), but the blob's userspace talks to Rockchip's proprietary kbase kernel driver (/dev/mali) and cannot attach to the mainline panthor driver: "libmali-valhall-g610-g13p0-gbm" → loads, exports NO Vulkan ICD (0 vk_* symbols) "libmali-valhall-g610-g24p0-gbm" libMaliVulkan.so.1 (api 1.3.276) → loads, "No mali devices found" then SIGSEGV (no /dev/mali) Installable packages exist (tsukumijima/libmali-rockchip releases, e.g. v1.9-1-20260312-bd33ee2), but they all presume the vendor kernel. Unblock: flash a vendor-kernel image (kernel with kbase/mali.ko, e.g. Armbian images with the Rockchip BSP kernel), then install libmali-valhall-g610-g13p0-gbm (or g24p0) and point Dawn/Vulkan at it (VK_DRIVER_FILES/LD_LIBRARY_PATH). That same blob also provides OpenCL 3.0 (libMaliOpenCL.so + /etc/OpenCL/vendors/mali.icd), which would additionally satisfy the "would OpenCL be faster?" curiosity — for running LLMs, both WebGPU/Vulkan and OpenCL on the same GPU land in the same class of throughput; the win is the mature compiler's fast startup, not raw speed. 7.3 OpenCL on the current kernel — not availableMesa's rusticl on panthor currently exposes zero devices (clinfo -l shows only the rusticl platform, no device). So there is no OpenCL device at all on the mainline stack, and LiteRT-LM has no Linux OpenCL accelerator anyway. 7.4 Practical advice for this board todayChat / streaming (decode-bound): CPU is the better lane — 12.3 vs 8.7 tk/s decode.Long prompts / RAG / document Q&A (prefill-bound): GPU pays off — 345 vs 124 tk/s prefill, 3.1 vs 8.4 s TTFT.Images / VL: --vision-backend gpu cuts vision-encode latency by ~2.7–3 s (~30%). Shortest VL TTFT is text+vision both on GPU (5.6 vs 8.9 s all-CPU), but keep the LLM on CPU when replies are short and chatty (6.2 s TTFT plus CPU-fast decode). --speculative-decoding true can lift decode further on both lanes (Gemma 4 E2B supports it).Serving an OpenAI-compatible endpoint (litert-lm serve)litert-lm serve exposes an OpenAI API on 0.0.0.0:9379, so LAN clients (LiteCode, opencode, aider, Continue, scripts) use the board like any OpenAI endpoint. Import a model once (litert-lm import ./gemma-4-E2B-it.litertlm, registry at ~/.litert-lm/models/), then litert-lm serve. Per-model settings come from ~/.litert-lm/config.json (default + models.<id>), so clients stay plain-OpenAI: { "default": { "backend": "cpu", "cpu_thread_count": 8, "cache": "disk" }, "models": { "gemma-4-E2B-it.litertlm": { "speculative_decoding": true, "max_num_tokens": 4096 } } } Endpoints: GET /v1/models and POST /v1/chat/completions (streaming + non-streaming). OpenAI tools / tool_choice are bridged to the model's function-calling template — verified to return valid tool_calls JSON (non-streaming and streamed) and to complete the full agent cycle (assistant tool_call → tool result → final answer). /v1/embeddings exists but is not tied to LLM models. Even though litert-lm describe reports Supports Function Call: NO for Gemma 4, the serve layer still bridges tools into the model template (empirically verified); that flag only means the CLI's interactive run has no native FC template. RAM budget (E2B, CPU): max_num_tokens preallocates KV/ringbuffer arenas up front.Measured process RSS: 4096 → ~3.1 GB (4.9 GB free — recommended), 8192 → ~7 GB (1.1 GB free — works but leaves no headroom). Keep 4096 and let clients budget. Config keys (0.15+): backend, vision_backend, audio_backend, cpu_thread_count, cache, max_num_tokens, speculative_decoding, thinking, thinking_budget, gpu_decode_steps_per_sync, sampling. CLI flags override config. For a persistent border, run under systemd. Verified client on this boardLiteCode (razvanneculai/litecode) — works end-to-end. Its Planner ({"synthesis","tasks"} strict JSON) and Executor (raw file content, no fences) prompts fit the 4096 budget; single-request task runs completed correctly and files linter-clean. litecode.json: { "provider": { "baseURL": "http://<yourIP>:9379/v1", "apiKey": "", "model": "gemma-4-E2B-it.litertlm" }, "tokenLimit": 4096, "reservedOutputTokens": 1500, "systemPromptBudget": 1000, "maxParallelExecutors": 1 } TroubleshootingFATAL ERROR: This binary was compiled with dotprod enabled... → CPU lacks FEAT_DotProd, not supported by the ARM64 prebuilt wheels. RK3588 has it. GPU benchmark errors but CPU works → with stock Mesa this is the §7.1 Dawn limit crash (maxImageDimension3D = 512); with the patched build, check vulkaninfo --summary again — panvk must list the Mali device and report maxImageDimension3D = 2048. ExportVK_ICD_FILENAMES+LD_LIBRARY_PATH for every run that should use the patched driver. Could not load shared library libLiteRtTopKWebGpuSampler.so → the CLI wheel does not bundle the WebGPU samplers; fetch them from the litert-lm repo prebuilt/linux_arm64/ at the matching version tag (e.g. v0.17.1) and export their directory on LD_LIBRARY_PATH. First GPU run is slow (one-time kernel compilation) — normal; use --cache disk so later loads skip it. Caches persist next to the model. Bigger models (e.g. stock gemma-4-E4B-it.litertlm, 3.66 GB) fail on the GPU even with the patched driver: panthor ... job timeout in dmesg (fixed 1 s driver watchdog, not tunable; the model has a one-shot dispatch that exceeds it even at the real 1 GHz boost) theVK_ERROR_DEVICE_LOST, and/or a global OOM-kill (EXIT=137) when pinned GPU buffers + the model outgrow 8 GB. E2B fits, E4B-stock doesn't. Use the text-only -web flavor (gemma-4-E4B-it-web.litertlm, 2.97 GB) for E4B-on-GPU — its finer kernels stay under the watchdog and its GPU set peaks ~4.3 GB (§5 E4B section). Join the conversation on the Armbian Forum and let us know how it runs on your hardware! View the full article

   • September 30Sep 30
9. [Armbian newsletter] - Armbian Newsletter October 2026
   

   [Armbian newsletter] - Armbian Newsletter October 2026

   admin posted a topic in SBC News

   Welcome to the latest Armbian newsletter! This development cycle brings a massive wave of progress across the entire ecosystem, packed with broad new board enablement, major platform maturation, and essential tooling upgrades. Highlights include: Extensive Board Enablement: Expanding support across multiple SoC families—including the EasePi R1, Pine64 Quartz64 Zero, ArmSoM CM7s IO board, Boardcon EM3588, Skysi X5 laptop, Banana Pi BPI-M4, Qualcomm Lenovo Legion Y700 Gen 4, NVIDIA Jetson Nano, Altera Agilex 5 SoCDK, Banana Pi R3 Mini, Firefly AIBOX-K3, Radxa Rock 2A/2F, and Anbernic handhelds like the RG Rotate. Bootloader & Kernel Modernization: A sweeping refresh moving numerous platforms to U-Boot v2026.10, TF-A lts-v2.14.11, and updated DDR blobs, alongside mainline kernel progression advancing to 7.3 across rockchip64, meson64, sunxi, and uefi targets. Deep Rockchip & Vendor Refinements: Major kernel, media, and wireless achievements, including 6 Gbps SATA on RK3588, RK3576 Panfrost GPU overlays, Amlogic VDEC fixes, and a consolidated rk35xx-vendor-next kernel branch. Tooling & Infrastructure Overhaul: Significant upgrades to the Armbian Imager (featuring Settings page, board-scoped profiles, and ext4 writer hardening), alongside refactored armbian-install, armbianmonitor, singlemode repository management with Acquire-By-Hash, and improved CI resilience. SPONSORED Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices. Github Highlights This cycle is defined by three themes: broad new board enablement, a coordinated U-Boot v2026.10 refresh across Rockchip and Allwinner platforms, and substantial Rockchip kernel, media, and wireless work. Board support expanded on multiple SoC families, including the EasePi R1 and Pine64 Quartz64 Zero on RK3568, the ArmSoM Your whole smart home, on a new board, before the coffee gets cold We moved our Home Assistant to a bigger board, and nothing needed re-pairing Our house runs on Armbian, and it has for years. Its Home Assistant setup started on an Allwinner H5 NanoPi K1 Plus. In 2025, it moved to the Rockchip NanoPi R3S LTS as soon as that Armbian Imager 2.5 is out Armbian Imager 2.5 sets up your board from a few simple questions, double-checks your storage before it writes, and now speaks Greek and Serbian. View the full article

   • October 28Oct 28
10. [News from Armbian] - Armbian Newsletter October 2026
    

    [News from Armbian] - Armbian Newsletter October 2026

    RSS Bot posted a topic in SBC News

    Welcome to the latest Armbian newsletter! This development cycle brings a massive wave of progress across the entire ecosystem, packed with broad new board enablement, major platform maturation, and essential tooling upgrades. Highlights include: Extensive Board Enablement: Expanding support across multiple SoC families—including the EasePi R1, Pine64 Quartz64 Zero, ArmSoM CM7s IO board, Boardcon EM3588, Skysi X5 laptop, Banana Pi BPI-M4, Qualcomm Lenovo Legion Y700 Gen 4, NVIDIA Jetson Nano, Altera Agilex 5 SoCDK, Banana Pi R3 Mini, Firefly AIBOX-K3, Radxa Rock 2A/2F, and Anbernic handhelds like the RG Rotate. Bootloader & Kernel Modernization: A sweeping refresh moving numerous platforms to U-Boot v2026.10, TF-A lts-v2.14.11, and updated DDR blobs, alongside mainline kernel progression advancing to 7.3 across rockchip64, meson64, sunxi, and uefi targets. Deep Rockchip & Vendor Refinements: Major kernel, media, and wireless achievements, including 6 Gbps SATA on RK3588, RK3576 Panfrost GPU overlays, Amlogic VDEC fixes, and a consolidated rk35xx-vendor-next kernel branch. Tooling & Infrastructure Overhaul: Significant upgrades to the Armbian Imager (featuring Settings page, board-scoped profiles, and ext4 writer hardening), alongside refactored armbian-install, armbianmonitor, singlemode repository management with Acquire-By-Hash, and improved CI resilience. SPONSORED Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices. Github HighlightsThis cycle is defined by three themes: broad new board enablement, a coordinated U-Boot v2026.10 refresh across Rockchip and Allwinner platforms, and substantial Rockchip kernel, media, and wireless work. Board support expanded on multiple SoC families, including the EasePi R1 and Pine64 Quartz64 Zero on RK3568, the ArmSoMYour whole smart home, on a new board, before the coffee gets coldWe moved our Home Assistant to a bigger board, and nothing needed re-pairing Our house runs on Armbian, and it has for years. Its Home Assistant setup started on an Allwinner H5 NanoPi K1 Plus. In 2025, it moved to the Rockchip NanoPi R3S LTS as soon as thatArmbian Imager 2.5 is outArmbian Imager 2.5 sets up your board from a few simple questions, double-checks your storage before it writes, and now speaks Greek and Serbian.View the full article

    • October 28Oct 28
11. Power domain error
    

    Power domain error

    blackc posted a topic in Allwinner CPU Boxes

    Hi! I have T95MAX v.2 board with H616 and AXP313A. I cannot up Panfrost acceleration, i think it because no renderD128 node at /dev/dri. Kernel module panfrost is laoded. Also, i' ve seen this strings at dmesg [ 1.658450] PM: always-on PM domain PLL is not on [ 1.658480] sun50i-h6-prcm-ppu 7010250.power-controller: Failed to add PLL power domain: -22 [ 1.658494] sun50i-h6-prcm-ppu 7010250.power-controller: probe with driver sun50i-h6-prcm-ppu failed with error -22 root@transpeed-8k618-t:~# ls /dev/dri by-path card0 root@transpeed-8k618-t:~# lsmod | grep panfrost panfrost 90112 0 drm_shmem_helper 28672 1 panfrost gpu_sched 57344 1 panfrost Is this dmesg error correlated with panfrost disfunction? Any ideas about this?

    • September 12Sep 12
    • 2 replies
12. H96 Max V58 Rockchip RK3588 Unofficial ARMBIAN
    

    H96 Max V58 Rockchip RK3588 Unofficial ARMBIAN

    Scrumpper posted a topic in Rockchip CPU Boxes

    It seemed like EVERYONE was talking about "looking into" getting Armbian going on this box. I did my best. Built from the Rock5b images. WiFi: Broadcom BCM43752 / AP6275P 802.11ax "WiFi 6" Panthor + Mesa GPU stack Open PanVK Vulkan + Panfrost GL GPU driver Gpu no longer pinned to 800MHz. Power toggles cycle it 600MHz, 800MHz, and 1000MHz. (the CPU also scales) Desktop compositing on the GPU A command is needed to set monitor resolution. Default is 1080p. Other Findings: CPU frequency was scanned under load: LITTLE cores (Cortex-A55): 1800 MHz BIG cores (Cortex-A76): 2208 MHz Those were the scaling_cur_freq readings. The vendor DTB caps the A76 at 2208 MHz: the physical max is 2.4 GHz but that OPP entry isn't in the table. Github repo: DOWNLOAD RELEASE FILES READ THE README.md! REFLASH STOCK IMAGE: UNPACKED FLASHING FILES FOR STOCK ANDROID README.md

    • July 14Jul 14
    • 11 replies
13. Making Allwinner H616 run armbian OS
    

    Making Allwinner H616 run armbian OS

    DrewAk49 replied to zcrself's topic in Allwinner CPU Boxes

    T95 H616 Mali-G31 Panfrost GPU Fix Problem: The Mali-G31 GPU was detected by the Panfrost driver, but GPU workloads would hang and fail with errors such as: gpu sched timeout gpu soft reset timed out gpu hard reset timed out error powering up gpu L2/shader/tiler The issue was not missing Panfrost support. The GPU was not being powered and initialized correctly due to device-tree power configuration. Fixes: 1. Increased GPU voltage The board was running the GPU regulator at 900mV. Changing vdd-gpu-sys to a fixed 950mV stabilized GPU operation. Device tree: regulator-min-microvolt = <950000>; regulator-max-microvolt = <950000>; regulator-name = "vdd-gpu-sys"; 2. Restored GPU power domain A previous workaround removed the GPU power domain: /delete-property/ power-domains; This allowed Panfrost to load but caused unstable GPU power management. Restored: power-domains = <&prcm_ppu 2>; 3. Linked the GPU regulator Added: mali-supply = <&reg_dcdcc>; This allows the Mali GPU driver to correctly control the GPU power supply. 4. Increased CMA memory Added kernel boot parameter: cma=128M The default 32MB CMA memory was increased to 128MB for improved DRM/display buffer reliability. Final working setup: - Kernel: Linux 7.3 - GPU: Mali-G31 Bifrost - Driver: Panfrost - GPU voltage: 950mV - PRCM GPU power domain enabled - CMA: 128MB Validation: GL_VENDOR: Panfrost GL_RENDERER: Mali-G31 (Panfrost) GL_VERSION: OpenGL ES 3.1 Repeated glmark2 tests completed successfully with no GPU scheduler timeouts. Conclusion: The T95 H616 Mali-G31 Panfrost issue was caused by incorrect GPU power sequencing in the device tree, not a lack of driver support. Correcting the regulator voltage, restoring the GPU power domain, linking the regulator, and increasing CMA memory resulted in stable hardware acceleration.

    • September 20Sep 20
    • 69 replies
14. Allwinner H616 T95 2gb/16gb
    

    Allwinner H616 T95 2gb/16gb

    DrewAk49 replied to kcahtoor's topic in Allwinner CPU Boxes

    T95 H616 Mali-G31 Panfrost GPU Fix Problem: The Mali-G31 GPU was detected by the Panfrost driver, but GPU workloads would hang and fail with errors such as: gpu sched timeout gpu soft reset timed out gpu hard reset timed out error powering up gpu L2/shader/tiler The issue was not missing Panfrost support. The GPU was not being powered and initialized correctly due to device-tree power configuration. Fixes: 1. Increased GPU voltage The board was running the GPU regulator at 900mV. Changing vdd-gpu-sys to a fixed 950mV stabilized GPU operation. Device tree: regulator-min-microvolt = <950000>; regulator-max-microvolt = <950000>; regulator-name = "vdd-gpu-sys"; 2. Restored GPU power domain A previous workaround removed the GPU power domain: /delete-property/ power-domains; This allowed Panfrost to load but caused unstable GPU power management. Restored: power-domains = <&prcm_ppu 2>; 3. Linked the GPU regulator Added: mali-supply = <&reg_dcdcc>; This allows the Mali GPU driver to correctly control the GPU power supply. 4. Increased CMA memory Added kernel boot parameter: cma=128M The default 32MB CMA memory was increased to 128MB for improved DRM/display buffer reliability. Final working setup: - Kernel: Linux 7.3 - GPU: Mali-G31 Bifrost - Driver: Panfrost - GPU voltage: 950mV - PRCM GPU power domain enabled - CMA: 128MB Validation: GL_VENDOR: Panfrost GL_RENDERER: Mali-G31 (Panfrost) GL_VERSION: OpenGL ES 3.1 Repeated glmark2 tests completed successfully with no GPU scheduler timeouts. Conclusion: The T95 H616 Mali-G31 Panfrost issue was caused by incorrect GPU power sequencing in the device tree, not a lack of driver support. Correcting the regulator voltage, restoring the GPU power domain, linking the regulator, and increasing CMA memory resulted in stable hardware acceleration.

    • September 20Sep 20
    • 8 replies
15. NATIVE ARM64 Steam Client Installer built on RK3588 board (Using the ARM64 Steam Frame's Client)
    

    NATIVE ARM64 Steam Client Installer built on RK3588 board (Using the ARM64 Steam Frame's Client)

    Scrumpper posted a topic in Advanced users - Development

    Valve published native ARM64 Steam in roughly April 2026. The Steam Frame launched September 14th. I built a client that installs the Steam Frame ARM64 Steam client on my RK3588 board. It launches Big Picture mode and firstboot makes you get past the VR Joystick screen. You can run it as desktop mode thereafter. The CLIENT and GAME run natively, naturally on ARM*. No box64 etc workarounds. Why not try to share if I can? *panvk and vulkan are required. This Contains: Vulkan feature layer for Direct3D translation layer Remote Play decode settings for GPU with no Vulkan Video, Private Mesa GLX copy for multi threaded OpenGL, Controller access rules for 243 pads Memory map limit for Proton Only tested on my H96 Max V58, RK3588 with Mali-G610 GPU. Armbian with an open grapics stack: Tested device answers: `panthor` loaded, renderer `Mali-G610 MC4 (Panfrost)`, Vulkandriver `panvk`, `ubuntu`, `4096`. **Rock 5B, Orange Pi 5 and other RK3588 boards on Armbian.** Same Mali-G610 as tested device. Pick Ubuntu based image. `current` and `edge` kernel branches are mainline and carry Panthor<--Should be fine. `vendor` branch: check `lsmod`: If `vulkaninfo` lists no `panvk` device, stock Mesa predates PanVK in use here :-( , `kisak-mesa` PPA is where the test device sources from. I may be under-educated but this might be able to run on a snapdragon chip or other ARM chip in a laptop or a mac. I have no idea. I do not own those things. I reached out to the Armbian Forums first since that is how this came about in the first place I NEED FEEDBACK!! Get it Here: https://github.com/Scrumpper/Steam-ARM/releases This project is not affiliated with, endorsed by or sponsored by Valve Corporation. Steam, Proton, Steam Deck and Steam Frame are trademarks of Valve Corporation.

    • September 26Sep 26
    • 25 replies
    • 2
    • • other
16. CSC Armbian for RK3288 TV Box boards (Q8)
    

    CSC Armbian for RK3288 TV Box boards (Q8)

    jock posted a topic in Rockchip CPU Boxes

    DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware. Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related). Thank you! This is CSC Armbian for XT-Q8L-V10 boards, also known as Chiptrip Q8, Vsmart Q8, ENY 3288 Q8, etc... All source code has been merged into Armbian mainline project. I still keep my personal public Armbian fork for experimental features: https://github.com/paolosabatino/armbian-build Nightly images: download directory Quick installation instructions on eMMC: Build or download your preferred Armbian image from Download directory and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the sd card, then push the power button for 1 second (the led will turn blue) After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed! Boot from SD Card/USB stick (with Armbian already installed in eMMC, empty eMMC or no eMMC😞 Build or download your preferred Armbian image from Download directory; Burn the image on your SD card/USB stick; Plug the SD card/USB stick in the device; Push the power button for 1 second (the led will turn blue); After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed! Boot from SD Card/USB stick (with original firmware or other firmware): In case your box has the original firmware installed, use the Multitool to erase the internal flash. Don't worry, you will not brick your box: once the eMMC is emptied, the box will automatically boot from SD Card. This is called Maskrom mode and is common to all Rockchip devices. Instructions and download links for the Multitool are at the bottom of this post. After erasing the internal eMMC, just follow the "Boot from SD Card" procedure above and then you are fine. Boot priority: Newer images (those with mainline kernel >= 4.14.50) now support booting from multiple devices. Priority is fixed and boot devices are probed in this order: External SD card External USB storage device (Any USB Stick/Hard drive attached to USB host ports) Internal eMMC This way even if you install armbian to internal eMMC, you can still easily test different images booting from external devices. Experts notes: when armbian is installed into eMMC you get U-boot installed too in eMMC. This is important to know because the box won't boot in Maskrom Mode, but instead will always boot the embedded U-boot, no matter if you put an sdcard/usb stick. In practice the embedded U-boot is totally responsible for the boot priority. If you want to restore the Maskrom Mode, just erase U-boot from eMMC using this command: dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=8128 conv=sync,fsync Current status: Wireless: works. pretty fast and stable, signal is strong on my box; Bluetooth: works. I was able to transfer files and stream audio without problems USB ports: works, with autosuspend too. A quick benchmark show that transfer rate is quite good (topped at 34 MB/s) USB OTG: works in host mode. Transfer rate is very good (> 40 MB/s) MMC: works and is perfectly accessible as storage device. The images above with "eMMC friendly" have been tested and work when installed in eMMC using the standard armbian-config eMMC installer SDCard: works. legacy kernel is limited to high speed, while mainline works fine in UHS mode too. A quick benchmark with a Samsung EVO card shows the promised 48Mb/s read speed. Gigabit Ethernet: works, fast and reliably HDMI: works perfectly Serial: works Audio: both HDMI audio and SPDIF connector works IR remote: works on legacy and mainline kernels Reboot/Suspend process: rebooting the device is a working in progress, at the moment sometimes it works and sometimes it doesn't. Suspend is still not available. Hardware acceleration: everything which works for rk3288 boards applies here too. This guide or maybe the Media Testing Script will help you gain an hardware accelerated X11 and Chromium (using GL4ES I enjoyed Quake 2 from the start till the end, but also Quake and Quake III Arena work flawlessy, here a quick how-to to compile and install GL4ES) Multimedia: On mainline kernel 3D acceleration is provided by Panfrost driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Multitool: The Multitool is a small but powerful tool to easy operate on internal eMMC flash of RK3288 devices. Features: Backup the content of internal eMMC Restore a previously backed-up image to eMMC Erase the eMMC (via fast blkdiscard or zero-fill as fallback) Burn an Armbian (or LibreELEC) image directly on the eMMC Provide a recovery shell for manual maintenance Windows-friendly: everything is placed in a NTFS partition Image compression format autodetection: they are decompressed on-the-fly during burn process Network support for remote maintenance via SSH (instructions to access via network here) Instructions are simple: Download the image from here Burn it on an sdcard Open the NTFS partition with your preferred file manager Place the images you want to burn on the device in images directory (backups will be stored in backups directory) Plug the sd card in the RK3288 device Power the device and wait few seconds, the Multitool menu will appear on screen and can be navigated with the keyboard Last edit: 07/06/2020 - updated installation instructions

    

    • May 6, 20188 yr
    • 228 replies
    • 4
17. [Collabora] - Kraid: A new compiler for Panfrost
    

    [Collabora] - Kraid: A new compiler for Panfrost

    RSS Bot posted a topic in SBC News

    Kraid is a new Rust-based compiler for Panfrost that replaces the aging Bifrost-rooted compiler stack with a cleaner, more flexible design for modern Mali GPUs, improving IR structure, register allocation, hardware testing, and long-term maintainability. View the full article

    • June 25Jun 25
18. panfrost fde60000.gpu: clk init failed -517
    

    panfrost fde60000.gpu: clk init failed -517

    j0ta posted a topic in Odroid M1

    On RK3568 the Panfrost driver needs the clk-scmi kernel module to be loaded. But is not build in 6.18 / 6.19 otherwise we get [ 13.370681] panfrost fde60000.gpu: get clock failed -517 [ 13.370717] panfrost fde60000.gpu: clk init failed -517 [ 13.485723] panfrost fde60000.gpu: get clock failed -517 [ 13.485761] panfrost fde60000.gpu: clk init failed -517 [ 13.503876] panfrost fde60000.gpu: get clock failed -517 [ 13.503918] panfrost fde60000.gpu: clk init failed -517 Thanks !

    • March 6Mar 6
    • 1 reply
    • • odroidm1
19. Power domain error
    

    Power domain error

    Boardcon_yang replied to blackc's topic in Allwinner CPU Boxes

    Yes, they're related — I'd treat the PPU probe failure as the direct reason you're not getting renderD128. On the H616 the Mali node in the device tree references a power domain provided by sun50i-h6-prcm-ppu. That driver registers three domains (PLL, ANA, GPU) out of two PRCM registers, and panfrost won't create its render node until the GPU domain exists and is powered. Your log shows the driver bailing out during probe, so the GPU domain never gets registered and panfrost keeps deferring forever. The -22 comes from the PLL entry: the driver marks it always-on, and the PM core refuses to register an always-on domain that reads as off at probe time — that's exactly what the "always-on PM domain PLL is not on" line means. The PLL gate is the active-low bit 2 in the PRCM VDD_SYS register, so you can check the real state with devmem 0x7010250 (bit 2 set = rail gated). Dev boards usually come up with that rail on because their bootloader enables it; plenty of TV boxes like the T95MAX leave it gated, which is why this mostly bites box owners. The clean workaround is to clear that bit before the kernel probes the PPU, e.g. from U-Boot: read the register with md.l, write it back with bit 2 cleared via mw.l. After that the driver should probe cleanly and panfrost should pick up the GPU domain and create the render node. Might also be worth reporting upstream that the driver hard-fails here instead of switching the always-on rail on itself — it would save every H616 box owner this detour.

    • September 15Sep 15
    • 2 replies
20. HOW-TO: Hardware video decode in "Google Chrome & Firefox" on RK3588 (Orange Pi 5B / Ubuntu-rockchip BSP)
    

    HOW-TO: Hardware video decode in "Google Chrome & Firefox" on RK3588 (Orange Pi 5B / Ubuntu-rockchip BSP)

    defcom5-rockchip replied to defcom5-rockchip's topic in Software, Applications, Userspace

    Making 2nd. post. || should we diff with Ghidra? sync Pi Claude's flicker memory notes so I'm not re-deriving something Pi Claude already nailed. Two good questions — let me answer the Ghidra one straight, then actually do the sync. Let me hunt down Pi Claude's flicker notes on the share and rockchip-notes: Bash Locate Pi Claude flicker memory notes on share/rockchip-notes IN echo "=== search share + rockchip-notes for Pi Claude's flicker memory notes ===" for base in "/mnt/orange/CLAUDE PI" "$HOME/rockchip-notes"; do [ -d "$base" ] && echo "--- under: $base ---" && \ find "$base" -type f \( -iname '*electron*' -o -iname '*compositing*' -o -iname '*flicker*' -o -iname '*vop2*' -o -iname '*video-playback*' -o -iname '*aquarium*' \) -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort -r done echo echo "=== also grep for the note SLUGS Pi Claude cited (in case they live in a memory/ dir) ===" grep -rl -iE 'electron-gpu-compositing-fix|flicker-4k120-vop2-timeout|video-playback-rk3588' "/mnt/orange/CLAUDE PI" "$HOME/rockchip-notes" 2>/dev/null | head OUT === search share + rockchip-notes for Pi Claude's flicker memory notes === --- under: /mnt/orange/CLAUDE PI --- 2026-08-25 16:55 /mnt/orange/CLAUDE PI/HANDOFF-PC-4k120-flicker-is-zerocopy-h264-decode.md 2026-08-25 16:30 /mnt/orange/CLAUDE PI/chrome-flicker/HANDOFF-to-Pi-Claude-flicker-capture.md 2026-08-01 14:44 /mnt/orange/CLAUDE PI/DRAFT-discussion-reply-crash-flicker.md 2026-07-30 08:00 /mnt/orange/CLAUDE PI/TESTCARD-v1.4-emmc-and-flicker.md 2026-06-25 12:28 /mnt/orange/CLAUDE PI/vop2-aclk-800-test.md --- under: /home/rich-defrese/rockchip-notes --- 2026-06-26 16:36 /home/rich-defrese/rockchip-notes/vop2-noflicker-patch.md 2026-06-25 13:36 /home/rich-defrese/rockchip-notes/vop2-aclk-800-test-RESULTS.md === also grep for the note SLUGS Pi Claude cited (in case they live in a memory/ dir) === /mnt/orange/CLAUDE PI/TEST-RESULTS-emmc-4k-crash-repro.md /mnt/orange/CLAUDE PI/HANDOFF-PC-4k120-flicker-is-zerocopy-h264-decode.md /mnt/orange/CLAUDE PI/HANDOFF-PC-construct-audio-RESULTS.md Pi Claude's canonical memory notes (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, etc.) aren't on the share — they live in Pi Claude's own memory on the Orange Pi, which I can't reach from here. But there ARE related notes on disk, including a vop2-noflicker-patch.md. Let me read the two most relevant: Read vop2-noflicker-patch.mdRead DRAFT-discussion-reply-crash-flicker.md Go Team Red! This sync just paid for itself — because I found the thing you were worried about: I was about to re-derive work you already finished. Let me answer Ghidra, then lay out what the sync turned up. Ghidra? No — and here's the proof Every flicker head we've actually cracked was solved by DRM plane-state / buffer-metadata diffing on open source, not binary RE: The AFBC one was nailed by matching DRM modifiers (flicker ⇔ AFBC 0x800000000000051, smooth ⇔ LINEAR 0x0) — a plane-state diff. Pi Claude's decode one was isolated by codec/decoder variable (zero-copy vs -copy) — a behavioral diff. The whole stack here is open: rockchip_drm_vop2.c, the woodyst VA-API driver, MPP, Mesa/Panfrost. Ghidra is for a closed binary with no source — libmali or the VPU firmware — and we haven't hit that wall. Reserve it for a real source dead-end; right now it'd be reaching for a scalpel when the patient's already open. The sync — you were 100% right to stop me The AFBC-disable lever I offered to "go scout" this session? Already root-caused on hardware AND patched — back in June. From ~/rockchip-notes/vop2-noflicker-patch.md: Windowed/composited 4K@120 flicker = AFBC-compressed scanout (proven on spare .181, 2026-06-25). VOP2 can't decompress AFBC in the 8.3 ms frame at 120 Hz; at 60 Hz/16.6 ms it fits. Ruled out DDR-bw, GPU, done-bit timeout, POST_BUF, aclk, PHY. Working fix: reject the AFBC modifier in rockchip_vop2_mod_supported() → linear scanout → no flicker. Branch pi-studio-lowlatency-noafbc. That's exactly the fix I was going to "discover." Done deal. The reconciled taxonomy — there are (at least) FOUR flickers #FlickerStatus 1AFBC scanout (4K@120 only)✅ fixed — noafbc patch / pi-studio-lowlatency-noafbc 2Zero-copy H.264 decode (green band)✅ fixed — use -copy decoder (Pi Claude, today) 3Chromium/Electron compositing glitch (Panfrost; ultrawide/resize; F11 clean)workarounds only — [[electron-gpu-compositing-fix]] 4VOP2 frame-done timeout (mode-level)[[flicker-4k120-vop2-timeout]] And here's the catch that reframes this session: you reported the browser flicker at 60 and 120. But the AFBC head is 120-only (60 fits in-frame). So the flicker you and I chased this session (VSCode/Vivaldi/Chromium, 60-too) is almost certainly head #3 — the Chromium/Panfrost compositing glitch — not AFBC. My whole AFBC/RGA framing this session was aimed at the wrong head. The gap Pi Claude's canonical notes for #3 and #4 (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, video-playback-rk3588) live in Pi Claude's memory on the Orange Pi — not on the share, so I can't read them from here. I reconstructed a lot from the on-disk notes, but to finish the sync cleanly I need those. Let me fold everything I can see into my memory now so we stop re-deriving, and I'll draft a short ask for Pi Claude to export its three canonical flicker notes to the share. Recording the reconciliation: Edit chrome-rk3588-hw-composition-flicker.md Added 8 lines 🔴 Go Team Red! — and appropriately, we didn't even have to break out the offensive tooling. No Ghidra required: the intel was already in-house, we just weren't reading our own files. The best recon is knowing what you already own. Sync is banked in memory — the four-headed flicker taxonomy, which heads are already killed (AFBC → noafbc patch; zero-copy H.264 → -copy decoder), and the correction that this session's browser flicker is head #3 (Chromium/Panfrost), not the AFBC one I was chasing. Future me won't re-derive it. One open item to finish the sync: Pi Claude's three canonical notes (electron-gpu-compositing-fix, flicker-4k120-vop2-timeout, video-playback-rk3588) live on the OPi, out of my reach. Want me to draft a quick handoff asking Pi Claude to export those to the share so I can fold head #3 and #4 in at full detail? That closes the last gap — then both of us are working from one map instead of two. Otherwise: real talk, that was a great catch on your part. "Sync before you scout" just saved us from rebuilding a June patch from scratch. 🔴🎸

    • August 26Aug 26
    • 17 replies
21. Making Allwinner H616 run armbian OS
    

    Making Allwinner H616 run armbian OS

    DrewAk49 replied to zcrself's topic in Allwinner CPU Boxes

    My T95 hardware: * **Model:** T95 Android TV Box * **SoC:** Allwinner H616 * **Board:** H616-T95MAX-V4.0 * **RAM:** 4GB DDR3 * **Internal storage:** 64GB eMMC * **Wi-Fi chip:** AW859A * **PMIC:** AXP305 * **Ethernet:** 100Mbps, using the AC200/AC300 internal PHY * **USB:** 2x USB 2.0 host ports * **Video:** HDMI output * **UART:** 3.3V logic * **Boot method:** Debian from microSD using mainline U-Boot * **Current OS:** Debian 12 Bookworm * **Current test kernel:** Linux 7.3-rc3 * **Stock Android:** still intact on eMMC Important detail: this is the **V4.0 board revision**, and some upstream T95 device-tree assumptions were based on other revisions. That mattered for things like the second USB port. T95 Box T95 H616 Linux issues and fixes so far: * **Only 2GB RAM showing** * Fixed with a U-Boot DRAM-size patch. Box now sees the full **4GB**. * **SD boot problems / wrong card detect** * Fixed by using the correct T95 device tree with the **PI16 SD card-detect GPIO**. * **Debian 7.3 kernel would not mount root** * `root=UUID=` failed without initramfs. * Fixed by using: `root=PARTUUID=fe8d38d0-eebf-4bb1-aa05-baafaf8c3f50` * **No HDMI output** * Added the H616 display-engine/HDMI patches and enabled HDMI in the T95 DTS. * HDMI now works at **1080p**. * **Ethernet not working** * Fixed H616 EMAC/AC200 PHY support. * Ethernet now links at **100Mbps full duplex**. * **One USB port had power but no data** * Stock Android DTS showed the V4.0 board also uses USB host 1. * Added: ```dts &ehci1 { status = "okay"; }; &ohci1 { status = "okay"; }; ``` * Both USB ports now work. * **Mali/Panfrost GPU acceleration** * Still being worked on. * Panfrost times out because of the H616 PRCM GPU power-domain path. This is the last major issue. Board: **H616-T95MAX-V4.0** OS: **Debian 12** Kernel testing: **Linux 7.3-rc3**

    • September 19Sep 19
    • 69 replies
22. OPI 4A - Allwinner T527
    

    OPI 4A - Allwinner T527

    Nick_Sl replied to JamesCL's topic in Allwinner sunxi

    I’ve published my experimental Sony IMX219 camera support for the Orange Pi 4A (Allwinner T527/A523). The project brings up the complete camera path on Linux 7.2.6: IMX219 → MIPI CSI-2/D-PHY → A523 CSI/VIN capture → V4L2. It includes a validated 22-patch kernel series, Device Tree integration, A523 MIPI D-PHY and CSI capture support, RAW10 capture, and an OpenCL/Rusticl/Panfrost userspace pipeline for debayering and YUV420 conversion. The current setup has been tested with 1920×1080 RAW10 capture and an approximately 10 FPS userspace streaming pipeline. The kernel patch series was also reproduced from a clean Linux 7.2.6 base and verified against the published aggregate patch. This is experimental bring-up work, not upstream-ready support yet. GitHub: https://github.com/nickslkr/orangepi-4a-imx219 Feedback, testing on other A523/T527 boards, and technical review are welcome.

    • October 1Oct 1
    • 213 replies
    • • orangepi4a
23. Panfrost power transition timeout errors
    

    Panfrost power transition timeout errors

    dreamlayers posted a topic in Amlogic CPU Boxes

    I have an x92 box with Amlogic Meson GXM (S912). The SOC has a Mali-T820 GPU, and the box has 2 GB of RAM and 16 GB of eMMC. I'm running Armbian 25.11.2 noble on it. While using the Wayfire Wayland GUI, there is a lot of kernel output like this, constantly repeating: panfrost d00c0000.gpu: shader power transition timeout panfrost d00c0000.gpu: tiler power transition timeout panfrost d00c0000.gpu: l2 power transition timeout The GUI works, and hardware 3D acceleration works. But it would be nice to get this spam out of the logs, and I also wonder if there is really some problem. Like, maybe the kernel doesn't know how to change GPU voltages. Maybe it is related to this at boot, maybe due to an issue with the device tree. kernel: panfrost d00c0000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found The only other sign of something being possibly wrong is that SOC temperature goes surprisingly high when playing hardware accelerated video. That ought to be energy efficient. I'm running Mopidy and Firefox at 53°C and just playing a video can get it to 70°C. It is possible to make these errors go away via: echo on | sudo tee /sys/bus/platform/devices/d00c0000.gpu/power/control I don't know if changing that from auto to on will increase power consumption. Alternatively I tried to add a dummy regulator to the device tree and set mali-supply of the GPU to that regulator. Adding the dummy regulator only removes this single error at boot time: panfrost d00c0000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found The power domain picture of the S912 datasheet shows a VDD_EE (Everything Else) input to the chip from an external PMIC, and then 3 components in the GPU, each with individual switches to VDD_EE. The 3 components are: GP0+L2C_0, PP0+L2C_1 and PP1. I suppose they correspond to the 3 types of power timeout errors, though I'm not sure which is which. This seems to show that there is no possibility for voltage scaling for individual GPU parts or even the whole GPU, without actually changing VDD_EE and everything else it powers. So, probably all the GPU driver needs to know is how to flip those three switches.

    • January 28Jan 28
    • 3 replies
24. panfrost fde60000.gpu: clk init failed -517
    

    panfrost fde60000.gpu: clk init failed -517

    j0ta replied to j0ta's topic in Odroid M1

    Bleedingedge Kernel 7.1 rc2 fixed it [ 12.686942] panfrost fde60000.gpu: clock rate = 594000000 [ 12.686994] panfrost fde60000.gpu: bus_clock rate = 500000000 [ 12.710029] panfrost fde60000.gpu: mali-g52 id 0x7402 major 0x1 minor 0x0 status 0x0 [ 12.710053] panfrost fde60000.gpu: features: 00000000,00000df7, issues: 00000000,00000400 [ 12.710062] panfrost fde60000.gpu: Features: L2:0x07110206 Shader:0x00000002 Tiler:0x00000209 Mem:0x1 MMU:0x00002823 AS:0xff JS:0x7 [ 12.710070] panfrost fde60000.gpu: shader_present=0x1 l2_present=0x1

    • May 8May 8
    • 1 reply
    • • odroidm1
25. OPI 4A - Allwinner T527
    

    OPI 4A - Allwinner T527

    AurealNix replied to JamesCL's topic in Allwinner sunxi

    Hi — I've been following this thread, the 100 Mbit ethernet cap and the silent mainline boot hang especially. I ended up doing a full mainline bring-up of the 4A on 6.18.38 and got gigabit ethernet working properly (RX/TX), plus the boot hang sorted, so I wanted to share the whole patch series in case it helps here. Full disclosure: I'm not a kernel developer by trade — I got most of this working with a lot of help from AI coding agents, leaning hard on the BSP 5.15 as the source of truth. In my own testing everything seems stable, but I'd genuinely welcome anyone who actually knows this stuff to review the patches and tell me what I got wrong or did in a hacky way. No egos here — I'm sharing it in case it's useful and to get feedback, not claiming it's perfect. 🙂 What works (confirmed on hardware): HDMI KMS display (DE33/DE3.5 + TCON-TV + DW-HDMI 2.0 + Inno PHY) — 720p/1080p, clean VSU8 scaling GPU Mali-G57 (Panfrost) — accelerated (KDE Plasma Wayland) HDMI audio (i2s2 → dw-hdmi) — PCM out to the TV Ethernet GMAC1 (YT8531 PHY, RGMII) — full gigabit RX/TX WiFi AP6256 (BCM43456, brcmfmac, SDIO) — 2.4/5 GHz scan + assoc reboot / poweroff (sunxi_wdt / AXP717) AFBC scanout (v350 AFBD decoder) USB — the 4 rear ports (all USB 2.0; the board doesn't wire the SoC's USB3) — HID + mass storage, hotplug THS thermal sensors (5 zones: cpu_l / cpu_b / gpu / npu / ddr) + 110 °C critical trip CPU cpufreq/DVFS (little cluster up to 1.416 GHz, big cluster up to 1.8 GHz) + thermal throttling GPU devfreq/DVFS (Panfrost, 150–600 MHz) + thermal throttling HDMI HPD / hotplug (native, no force) Known not working / help wanted: eMMC — not tested (I don't have a module). I saw the mmc2: error -110 reports earlier in the thread; happy to dig into it with anyone who has eMMC. Hardware video decode (VPU) — no driver in 6.18 yet (software decode works). Suspend/hibernate — untested. 4GB variant — expected to work out of the box (the bootloader auto-detects the RAM size and fills in /memory at boot; verified over UART on the 2GB board). I only own the 2GB variant, so if you have the 4GB one, a free -h confirmation would be very welcome. NVMe SSD — untested, no drive here. Everything so far has only run from microSD. Freshness note: the cpufreq/thermal/GPU-devfreq block landed this very week and is still under soak testing on my board — everything else has more mileage. I'll report anything that shakes out in this thread. Repo / patches: https://github.com/ut-slayer/orangepi-4a-mainline It's a git format-patch series (~106 patches) on top of 6.18.38 vanilla, plus a defconfig and the board .dts. The README groups the patches by intended destination: generic sunxi fixes (pinctrl, watchdog vs PSCI, AXP717 poweroff, a RESET_GPIO/mmc-pwrseq bug affecting any sunxi board with SDIO WiFi), the HDMI KMS display series (largely ported/adapted from the minimyth2 / Justin Suess H728 work, with original authorship kept in the patch headers), the A523 CPU CCU + thermal + DVFS, board integration (dts + defconfig), and a few U-Boot BSP workarounds that go away with mainline U-Boot. Coming next: a ready-to-flash Debian 13 (Trixie) image with accelerated Panfrost and KDE Plasma on Wayland — I'll share it in this thread once it's had a bit more soak testing. Happy to open a PR against armbian/build (sun55iw3 family) with the board dts + defconfig + patches if there's interest. Feedback and testers welcome! Credits: minimyth2 / Justin Suess for the H728 display groundwork, and the linux-sunxi community. Cheers.

    • July 14Jul 14
    • 213 replies
    • • orangepi4a