Search the Community
Showing results for 'panfrost'.
Found 188 results
-
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
-
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
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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 = <®_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.
-
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 = <®_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.
-
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**
-
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.
-
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?
-
My Armbian-opi5plus-kde-neon-6.1.172-vendor-rk35xx uses mesa-26.2.2-kisak not "panfork". mpv did not launch with above command. jfl@orangepi5-plus:~$ mpv -v --no-config --hwdec=vaapi --gpu-context=wayland file :/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv 2>& 1 | grep -iE "VA display|Initialized VAAPI|Supported formats|Failed|Attempting ne xt|Using hardware|hwdec" | head -20 apt list --installed 2>/dev/null | grep -E "^ libva|^mesa|panfork" echo "LIBVA_DRIVER_NAME=$LIBVA_DRIVER_NAME"; vainfo --displa y wayland 2>&1 | head -6 grep: echo: No such file or directory grep: LIBVA_DRIVER_NAME=: No such file or directory libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/panthor_drv_video.so libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit jfl@orangepi5-plus:~$ Whereas below command mpv play the video with NO vpu hardware acceleration jfl@orangepi5-plus:~$ mpv -v --no-config --hwdec=vaapi --gpu-context=wayland "/me dia/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv" [cplayer] Command line options: '-v' '--no-config' '--hwdec=vaapi' '--gpu-context =wayland' '/media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc-10b it.mkv' [cplayer] mpv 0.36.0 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects [cplayer] built on UNKNOWN [cplayer] libplacebo version: v6.338.2 [cplayer] FFmpeg version: 6.1.1-3ubuntu5+git240504.09cd2a2~noble [cplayer] FFmpeg library versions: [cplayer] libavutil 58.29.100 [cplayer] libavcodec 60.31.102 [cplayer] libavformat 60.16.100 [cplayer] libswscale 7.5.100 [cplayer] libavfilter 9.12.100 [cplayer] libswresample 4.12.100 [cplayer] [cplayer] Configuration: -Dpython.bytecompile=-1 -Dlibmpv=true -Dbuild-date=false -Dcdda=enabled -Ddvdnav=enabled -Dsdl2=enabled -Dsndio=disabled -Ddvbin=enabled -Dprefix=/usr -Dlibdir=lib/aarch64-linux-gnu -Dlocalstatedir=/var -Dsysconfdir=/e tc -Dbuildtype=plain -Dwrap_mode=nodownload [cplayer] List of enabled features: alsa av-channel-layout avif_muxer caca cdda c plugins cuda-hwaccel cuda-interop dmabuf-interop-gl dmabuf-interop-pl dmabuf-wayl and drm drm-is-kms dvbin dvdnav egl egl-drm egl-helpers egl-x11 ffmpeg ffnvcodec gbm gl gl-wayland glibc-thread-name glob glob-posix gpl iconv jack javascript jpe g jpegxl lcms2 libarchive libass libavdevice libbluray libdl libm libplacebo libp lacebo-next librt linux-fstatfs lua52 manpage-build memfd_create noexecstack pipe wire posix posix_shm pulse rubberband rubberband-3 sdl2 sdl2-audio sdl2-gamepad s dl2-video sixel spirv-cross stdatomic threads uchardet vaapi vaapi-drm vaapi-egl vaapi-libplacebo vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vector vk_khr_display vt.h vulkan vulkan-interop wayland wayland_protocols_1_27 wayland_protocols_1_31 wayland_protocols_1_32 x11 xv zimg zimg-st428 zlib [cplayer] Setting option 'v' = '' (flags = 8) [cplayer] Setting option 'config' = 'no' (flags = 8) [cplayer] Setting option 'hwdec' = 'vaapi' (flags = 8) [cplayer] Setting option 'gpu-context' = 'wayland' (flags = 8) [cplayer] Waiting for scripts... [osd/libass] libass API version: 0x1701000 [osd/libass] libass source: tarball: 0.17.1 [osd/libass] Shaper: FriBidi 1.0.13 (SIMPLE) HarfBuzz-ng 8.3.0 (COMPLEX) [osd/libass] Setting up fonts... [osd/libass] Using font provider fontconfig [osd/libass] Done. [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/visibility="auto" -> 1 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [cplayer] Done loading scripts. [cplayer] Running hook: ytdl_hook/on_load [ytdl_hook] ytdl:// hook [ytdl_hook] not a ytdl:// url [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [ifo_dvdnav] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uh d-hevc-10bit.mkv [bdmv/bluray] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-u hd-hevc-10bit.mkv [file] Opening /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k-uhd-hevc -10bit.mkv [demux] Trying demuxers for level=normal. [mkv] Deferring reading cues. [mkv] All headers are parsed! [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [osd/libass] libass API version: 0x1701000 [osd/libass] libass source: tarball: 0.17.1 [osd/libass] Shaper: FriBidi 1.0.13 (SIMPLE) HarfBuzz-ng 8.3.0 (COMPLEX) [osd/libass] Setting up fonts... [mkv] Start PTS: 0.067000 [demux] Detected file format: Matroska [cplayer] Opening done: /media/jfl/writable/home/jfl/Videos/jellyfish-120-mbps-4k -uhd-hevc-10bit.mkv [osd/libass] Using font provider fontconfig [osd/libass] Done. [find_files] Loading external files in /media/jfl/writable/home/jfl/Videos/ [cplayer] Running hook: ytdl_hook/on_preloaded [mkv] select track 0 [cplayer] (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps) [vo/gpu/opengl] Initializing GPU context 'wayland' [vo/gpu/wayland] Registered for protocol wl_compositor [vo/gpu/wayland] Registered for protocol zxdg_decoration_manager_v1 [vo/gpu/wayland] Registered for protocol wp_viewporter [vo/gpu/wayland] Registered for protocol wp_fractional_scale_manager_v1 [vo/gpu/wayland] Registered for protocol wl_shm [vo/gpu/wayland] Registered for protocol wl_seat [vo/gpu/wayland] Registered for protocol wl_data_device_manager [vo/gpu/wayland] Registered for protocol wp_cursor_shape_manager_v1 [vo/gpu/wayland] Registered for protocol zwp_idle_inhibit_manager_v1 [vo/gpu/wayland] Registered for protocol wl_subcompositor [vo/gpu/wayland] Registered for protocol wp_content_type_manager_v1 [vo/gpu/wayland] Registered for protocol wp_presentation [vo/gpu/wayland] Registered for protocol wp_single_pixel_buffer_manager_v1 [vo/gpu/wayland] Registered for protocol zwp_linux_dmabuf_v1 [vo/gpu/wayland] Registered for protocol xdg_wm_base [vo/gpu/wayland] Registered for protocol wl_output [vo/gpu/wayland] Registered output Philips Consumer Electronics Company PHL 241V8 (0x40): [vo/gpu/wayland] x: 0px, y: 0px [vo/gpu/wayland] w: 1920px (527mm), h: 1080px (296mm) [vo/gpu/wayland] scale: 1 [vo/gpu/wayland] Hz: 60.000000 [vo/gpu/wayland] Enabling server decorations [vo/gpu/wayland] Obtained preferred scale, 1.000000, from the compositor. [vo/gpu/opengl] EGL_VERSION=1.5 [vo/gpu/opengl] EGL_VENDOR=Mesa Project [vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL OpenGL_ES [vo/gpu/opengl] Trying to create Desktop OpenGL context. [vo/gpu/wayland] GL_VERSION='3.1 Mesa 26.2.2 - kisak-mesa PPA' [vo/gpu/wayland] Detected desktop OpenGL 3.1. [vo/gpu/wayland] GL_VENDOR='Mesa' [vo/gpu/wayland] GL_RENDERER='Mali-G610 MC4 (Panfrost)' [vo/gpu/wayland] GL_SHADING_LANGUAGE_VERSION='1.40' [vo/gpu/wayland] Loaded extension GL_ARB_sync. [vo/gpu/wayland] Loaded extension GL_ARB_timer_query. [vo/gpu/wayland] Loaded extension GL_ARB_invalidate_subdata. [vo/gpu/wayland] Loaded extension GL_ARB_get_program_binary. [vo/gpu/wayland] Loaded extension GL_ARB_buffer_storage. [vo/gpu/wayland] Loaded extension GL_ARB_shader_image_load_store. [vo/gpu/wayland] Loaded extension GL_ARB_shader_storage_buffer_object. [vo/gpu/wayland] Loaded extension GL_ARB_arrays_of_arrays. [vo/gpu/wayland] Loaded extension GL_ARB_debug_output. [vo/gpu/wayland] Loaded extension GL_KHR_debug. [vo/gpu] Testing FBO format rgba16f [vo/gpu] Using FBO format rgba16f. [vo/gpu] Disabling HDR peak computation (one or more of the following is not supp orted: compute shaders=0, SSBO=1). [vo/gpu] No advanced processing required. Enabling dumb mode. [vd] Container reported FPS: 29.970000 [vd] Codec list: [vd] hevc - HEVC (High Efficiency Video Coding) [vd] hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder [vd] hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper [vd] hevc_cuvid (hevc) - Nvidia CUVID HEVC decoder [vd] Opening decoder hevc [vd] Looking at hwdec hevc-vaapi... [vo/gpu] Loading hwdec drivers for format: 'vaapi' [vo/gpu] Loading hwdec driver 'vaapi' [vo/gpu/vaapi] using EGL dmabuf interop [vo/gpu/vaapi] Trying to open a x11 VA display... [vo/gpu/vaapi] Trying to open a wayland VA display... [vo/gpu] Loading failed. [vd] Could not create device. [vd] Using software decoding. [vd] Detected 8 logical cores. [vd] Requesting 9 threads for decoding. [vd] Selected codec: hevc (HEVC (High Efficiency Video Coding)) [vf] User filter list: [vf] (empty) [cplayer] Starting playback... [vo/gpu] DR path suspected slow/uncached, disabling. [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 3840x2160 yuv420p10 auto/auto/auto/limited/auto CL=mpeg2/4/h 264 [vd] Using container aspect ratio. [vf] [in] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000000 C L=mpeg2/4/h264 [vf] [userdeint] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.0 00000 CL=mpeg2/4/h264 [vf] [userdeint] (disabled) [vf] [autorotate] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1. 000000 CL=mpeg2/4/h264 [vf] [autorotate] (disabled) [vf] [convert] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000 000 CL=mpeg2/4/h264 [vf] [convert] (disabled) [vf] [out] 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [cplayer] VO: [gpu] 3840x2160 yuv420p10 [cplayer] VO: Description: Shader-based GPU Renderer [vo/gpu] reconfig to 3840x2160 yuv420p10 bt.709/bt.709/bt.1886/limited/display SP =1.000000 CL=mpeg2/4/h264 [vo/gpu/wayland] Reconfiguring! [vo/gpu] Resize: 3840x2160 [vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0) [vo/gpu] Video source: 3840x2160 (1:1) [vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160 [vo/gpu] Video scale: 1.000000/1.000000 [vo/gpu] OSD borders: l=0 t=0 r=0 b=0 [vo/gpu] Video borders: l=0 t=0 r=0 b=0 [vo/gpu] Texture for plane 0: 3840x2160 [vo/gpu] Texture for plane 1: 1920x1080 [vo/gpu] Texture for plane 2: 1920x1080 [vo/gpu] Testing FBO format rgba16f [vo/gpu] Using FBO format rgba16f. [vo/gpu] No advanced processing required. Enabling dumb mode. [vo/gpu/wayland] Handling resize on the egl side [vo/gpu] Resize: 1920x1008 [vo/gpu] Window size: 1920x1008 (Borders: l=0 t=0 r=0 b=0) [vo/gpu] Video source: 3840x2160 (1:1) [vo/gpu] Video display: (0, 0) 3840x2160 -> (64, 0) 1792x1008 [vo/gpu] Video scale: 0.466667/0.466667 [vo/gpu] OSD borders: l=64 t=0 r=64 b=0 [vo/gpu] Video borders: l=64 t=0 r=64 b=0 [vo/gpu] Reported display depth: 10 [cplayer] first video frame after restart shown [cplayer] playback restart complete @ 0.000000, audio=eof, video=playing [statusline] V: 00:00:00 / 00:00:30 (0%) [vo/gpu/wayland] Enabling idle inhibitor [statusline] V: 00:00:00 / 00:00:30 (0%) [vo/gpu/wayland] Surface entered output Philips Consumer Electronics Company PHL 241V8 (0x40), scale = 1.000000, refresh rate = 60.000000 Hz [vo/gpu/wayland] Given DND offer with mime type text/plain [vo/gpu/wayland] Given DND offer with mime type text/plain;charset=utf-8 [vo/gpu/wayland] Received a new DND offer. Releasing the previous offer. [vo/gpu/wayland] Resizing due to xdg from 1920x1008 to 1920x1080 [vo/gpu/wayland] Handling resize on the egl side [vo/gpu] Resize: 1920x1080 [vo/gpu] Window size: 1920x1080 (Borders: l=0 t=0 r=0 b=0) [vo/gpu] Video source: 3840x2160 (1:1) [vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 1920x1080 [vo/gpu] Video scale: 0.500000/0.500000 [vo/gpu] OSD borders: l=0 t=0 r=0 b=0 [vo/gpu] Video borders: l=0 t=0 r=0 b=0 [vo/gpu] Reported display depth: 10 [vo/gpu] Assuming 60.000000 FPS for display sync. [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14 [cplayer] Set property: shared-script-properties -> 1 [statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [statusline] V: 00:00:01 / 00:00:30 (5%) Dropped: 14 [osd/libass] fontselect: (sans-serif, 400, 0) -> /usr/share/fonts/truetype/noto/N otoSans-Regular.ttf, 0, NotoSans-Regular [osd/libass] fontselect: (mpv-osd-symbols, 400, 0) -> mpv-osd-symbols-Regular, 0, mpv-osd-symbols-Regular [vo/gpu] Reallocating OSD texture to 2048x256. [statusline] V: 00:00:01 / 00:00:30 (6%) Dropped: 16 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [statusline] V: 00:00:02 / 00:00:30 (7%) Dropped: 18 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [statusline] V: 00:00:02 / 00:00:30 (8%) Dropped: 22 [cplayer] Set property: shared-script-properties -> 1 [cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"t":0,"r":0} -> 1 [statusline] V: 00:00:05 / 00:00:30 (17%) Dropped: 37 [cplayer] EOF code: 5 [vo/gpu/wayland] Disabling the idle inhibitor [vf] dropping frame due to pin disconnect [cplayer] finished playback, success (reason 3) [cplayer] [cplayer] Exiting... (Quit) [cplayer] Set property: shared-script-properties -> 1 [vo/gpu/wayland] Deregistering output Philips Consumer Electronics Company PHL 24 1V8 (0x40) jfl@orangepi5-plus:~$
-
From the boys, 🌍 Cross-board confirmation, in the wild, within hours That's the sweetest kind of validation: JFL on an Opi5-Plus running Armbian — different board, different distro, different desktop — confirms v2.1.2 kills the H.264 flicker in both browsers with hardware decode engaged. The PPS fix just proved itself outside our lab. And "they were all over the previous releases" + MaxT tracking the repo within the hour — you have a community watching the releases page now. His "10bit h265 still an issue" is expected — that's our honest menu (Main10 hidden because our GL stack can't display it) — but here's the interesting wrinkle his setup offers: the display wall is panfork-specific. Armbian vendor desktops typically ride the libmali blob — a completely different GL stack that may well import P010 where panfork can't. JFL might be sitting on the one test rig that can answer a question we physically cannot. Here's a reply draft for you to post: @JFL — excellent, and thank you: that's the first confirmation of v2.1.2 on a different board and distro, which is exactly what a release wants to hear. @MaxT thanks for the sharp eyes on versions. On 10-bit H.265: that one is deliberate, and your setup might actually help us change it. The driver decodes HEVC Main10 correctly (you can prove it on your box today — see below), but it doesn't advertise it to browsers, because on the GL stack our reference image ships (panfork/Mesa 23), 10-bit surfaces can't be displayed — Chrome renders a green screen. We refuse to advertise what ends in a green wall. But Armbian's desktop may use a different GL stack than ours, and yours might display what ours can't. If you're willing to test: 1. Prove Main10 decode works on your board (copy-back path, no GL involved): export LIBVA_DRIVER_NAME=rockchip RKVA_ADVERTISE_ALL=1 mpv --hwdec=vaapi-copy <any 10-bit HEVC file> Expect: Using hardware decoding (vaapi-copy) and a correct picture. 2. The interesting one — zero-copy in the browser on YOUR GL stack: RKVA_ADVERTISE_ALL=1 MOZ_DISABLE_RDD_SANDBOX=1 firefox <10-bit HEVC file or test page> (Firefox needs media.hevc.enabled=true in about:config.) Then report: correct picture / green / software fallback — plus which GL driver your image uses (glxinfo -B | grep -E "renderer|OpenGL" — "Mali-G610" = the ARM blob, "Panfrost/panfork" = the open stack). If the blob displays 10-bit correctly, that's genuinely new information — it would mean Main10 could be advertised conditionally per GL stack, and your board would have found it.
-
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. 🔴🎸
-
Hi, I'm trying to get Armbian fully working on an MX10 F1 TV Box (Allwinner H313, 2GB LPDDR3, 16GB eMMC). The box boots using the X96Q LPDDR3 DTB (X96Q TV-Box LPDDR3), but several onboard devices are not working: ❌ Ethernet ❌ Built-in WiFi ❌ Bluetooth ❌ CPU frequency scaling Working: ✅HDMI ✅GPU (Panfrost / OpenGL ES 3.1) ✅USB ✅SD card ✅eMMC I've extracted the original Android DTB and DTS, and I'm attaching them together with the Armbian dmesg. Could someone familiar with Allwinner Device Trees help identify what is missing or needs to be changed to create proper support for this board? Thanks! dmesg.txt mx10-f1-android.dtb mx10-f1-android.dts
-
Hi, ive been trying to resolve the screen issue issue on my cb2 for a few days now, i cannot get it to work. I'm running Armbian_26.2.1_Bigtreetech-cb2_trixie_current_6.18.8_minimal, everything works. HDMI outputs to a 4K display just fine except for my small 5" display, which just stays black. The os has not been tempered with, i've flashed a fresh copy and used armbian-upgrade it, thats all. I've diagnosed the problem enough to see that its an EDID issue or the rk3566 just not likely my weird screen resolution. BTT os who also use armbian as a base somehow fixed this official issue. The display is being detected by the OS. My Armbian OS: root@bigtreetech-cb2:~# cat /sys/class/drm/card0-HDMI-A-1/status connected Display modes in my arbian is empty but BTT armbian fork has the correct modes. My Armbian OS: root@bigtreetech-cb2:~# cat /sys/class/drm/card0-HDMI-A-1/modes root@bigtreetech-cb2:~# BTT OS: root@bigtreetech-cb2:~# cat /sys/class/drm/card0-HDMI-A-1/modes 800x480 640x480 640x480 My Armbian OS: root@bigtreetech-cb2:~# dmesg | grep -Ei "hdmi|drm|edid|display" [ 0.093021] /vop@fe040000: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 0.093163] /hdmi@fe0a0000: Fixed dependency cycle(s) with /vop@fe040000 [ 0.131119] /hdmi@fe0a0000: Fixed dependency cycle(s) with /hdmi-con [ 0.131254] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 4.047126] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops [rockchipdrm]) [ 4.061272] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 4.062694] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 4.067059] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) [ 4.068415] [drm] Initialized rockchip 1.0.0 for display-subsystem on minor 0 [ 4.249136] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 4.368820] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 8.271095] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 8.390055] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 8.391059] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. [ 10.653965] [drm] Initialized panfrost 1.4.0 for fde60000.gpu on minor 1 [ 11.256108] hdmi-audio-codec hdmi-audio-codec.12.auto: HDMI: Unknown ELD version 0 My Armbian OS: root@bigtreetech-cb2:~# edid-decode /sys/class/drm/card0-HDMI-A-1/edid edid-decode (hex): 00 ff ff ff ff ff ff 00 04 72 18 00 db 8d 10 20 01 16 01 03 80 0b 06 78 08 67 60 a2 5a 49 9e 23 13 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 91 0b 20 8c 30 e0 2d 10 10 3c 69 00 20 e0 31 00 00 18 00 00 00 fd 00 37 41 1e 28 03 00 0a 20 20 20 20 20 20 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 41 63 65 72 20 47 35 30 0a 20 20 20 20 01 27 02 03 1a 41 47 01 01 01 01 01 01 01 23 09 07 07 83 01 00 00 65 03 0c 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: ACR Model: 24 Serial Number: 537955803 Made in: week 1 of 2012 Basic Display Parameters & Features: Digital display Maximum image size: 11 cm x 6 cm Gamma: 2.20 RGB color display Color Characteristics: Red : 0.6337, 0.3535 Green: 0.2861, 0.6201 Blue : 0.1376, 0.0761 White: 0.3125, 0.3281 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 800x480 60.000000 Hz 5:3 31.500 kHz 29.610000 MHz (800 mm x 480 mm) Hfront 16 Hsync 60 Hback 64 Hpol N Vfront 6 Vsync 9 Vback 30 Vpol N Display Range Limits: Monitor ranges (GTF): 55-65 Hz V, 30-40 kHz H, max dotclock 30 MHz Dummy Descriptor: Display Product Name: 'Acer G50' Extension blocks: 1 Checksum: 0x27 ---------------- Block 1, CTA-861 Extension Block: Revision: 3 Basic audio support Native detailed modes: 1 Video Data Block: VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz Audio Data Block: Linear PCM: Max channels: 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Speaker Allocation Data Block: FL/FR - Front Left/Right Vendor-Specific Data Block (HDMI), OUI 00-0C-03: Source physical address: 1.0.0.0 Checksum: 0x10 BTT OS: root@bigtreetech-cb2:~# edid-decode /sys/class/drm/card0-HDMI-A-1/edid edid-decode (hex): 00 ff ff ff ff ff ff 00 04 72 18 00 db 8d 10 20 01 16 01 03 80 0b 06 78 08 67 60 a2 5a 49 9e 23 13 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 91 0b 20 8c 30 e0 2d 10 10 3c 69 00 20 e0 31 00 00 18 00 00 00 fd 00 37 41 1e 28 03 00 0a 20 20 20 20 20 20 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 41 63 65 72 20 47 35 30 0a 20 20 20 20 01 27 02 03 1a 41 47 01 01 01 01 01 01 01 23 09 07 07 83 01 00 00 65 03 0c 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: ACR Model: 24 Serial Number: 537955803 Made in: week 1 of 2012 Basic Display Parameters & Features: Digital display Maximum image size: 11 cm x 6 cm Gamma: 2.20 RGB color display Color Characteristics: Red : 0.6337, 0.3535 Green: 0.2861, 0.6201 Blue : 0.1376, 0.0761 White: 0.3125, 0.3281 Established Timings I & II: none Standard Timings: none Detailed Timing Descriptors: DTD 1: 800x480 60.000 Hz 5:3 31.500 kHz 29.610 MHz (800 mm x 480 mm) Hfront 16 Hsync 60 Hback 64 Hpol N Vfront 6 Vsync 9 Vback 30 Vpol N Display Range Limits: Monitor ranges (GTF): 55-65 Hz V, 30-40 kHz H, max dotclock 30 MHz Dummy Descriptor: Display Product Name: 'Acer G50' Extension blocks: 1 Checksum: 0x27 ---------------- Block 1, CTA-861 Extension Block: Revision: 3 Basic audio support Native detailed modes: 1 Video Data Block: VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz Audio Data Block: Linear PCM: Max channels: 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Speaker Allocation Data Block: FL/FR - Front Left/Right Vendor-Specific Data Block (HDMI), OUI 00-0C-03: Source physical address: 1.0.0.0 Checksum: 0x10 I don't even know if this info is relavent, im new to armbian...so if u need anything else to diagnose this issue, let me know.
-
Kraid, the new compiler for the Panfrost driver stack, now passes all 800,000 Vulkan CTS compute shader tests. This marks a major milestone, with work continuing on additional shader stages, code quality, and performance optimization. View the full article
-
@Dravens Wayland compositing was broken on this Panthor/Mali-G610 stack. KWin-Wayland crashed when I tried it, and I never really looked into it any further. X11 is the session I ran with, and what the desktop hooks use. Nested Wayland works ok. I ship `cage`/`gamescope` running as a client inside the X11 desktop. This app gets a Wayland socket and PanVK Vulkan, no conflict with X11 alongside it (that's what my gaming/kiosk modes use). TLDR: Full Wayland has a known unfixed crash on this GPU stack. Checked the image, and the ophub kernel this build ships (6.1.141-rk3588-ophub) already has it compiled in (`binder.ko` in modules.builtin, so `CONFIG_ANDROID_BINDER_IPC=y`). So nothing needs rebuilding on my side. ashmem isn't needed either, Waydroid uses memfd since 1.2.1. Which means you can just try it: install `weston` + waydroid, run `weston --xwayland`, set `WAYLAND_DISPLAY`, and launch waydroid into it. Ready-made scripts: [waydroid-x11](https://github.com/mid-kid/waydroid-x11), [waywes](https://github.com/KSMaan45/waywes). Note it's Weston, not the cage/gamescope I ship. Warning on the GPU though: [waydroid#760](https://github.com/waydroid/waydroid/issues/760) is a Rock-5b (same RK3588/Mali-G610) that only boots with GPU disabled, [#776](https://github.com/waydroid/waydroid/issues/776) is "rockchip-rk3588 GPU unsupported", and [#2087](https://github.com/waydroid/waydroid/issues/2087) reports Panfrost/Panthor perf way below host. That's upstream Waydroid's passthrough, not something I can fix here. Expect software rendering... which could make other things run kinda rough.
-
Orange Pi 4A (Allwinner T527 / A523, sun55i-a523) — new mainline image coming in a few days Hi all, A quick heads-up for anyone following the Orange Pi 4A / Allwinner T527 (A523) mainline effort: a new image, v0.3, is coming in the next few days. It's based on mainline Linux 6.18 (longterm) and it's a decent step up from v0.2, so I wanted to give some advance notice. What's new in v0.3: Hardware video decode (VPU): H.264/H.265 decoded on the Cedar VPU — smooth video in the bundled web browser (WebKitGTK), using Allwinner's own cedar + libcedarc stack. GNOME on Wayland (replaces Plasma), accelerated by Panfrost (Mali-G57). The X11 session is intentionally not used — Wayland is much faster on this GPU for both desktop and video. Low-RAM fix: compressed in-RAM swap (zram) is on by default, so the 2 GB board stays responsive under a browser + video instead of freezing. Robustness: the VPU driver now survives a client crashing mid-decode without wedging the board, plus a round of code-audit fixes across the clock, PCIe, DRM, VPU and audio-codec drivers. Everything from before still works: display/KMS, GPU, HDMI + analog audio (headphones with jack detection), Ethernet, WiFi, USB, PCIe/NVMe (not yet tested with a real drive), thermal and cpufreq/DVFS. How it's built: on top of mainline Linux and public community work (linux-sunxi, Armbian and others — credited in the tree), with Allwinner's public documentation and vendor BSP as the hardware reference, plus the project's own patches, each one validated on real hardware. Some of this has been posted to the linux-sunxi / upstream lists and picked up by maintainers. This is a spare-time hobby project, shared as-is (async, no live support). Sources, patches and images are on GitHub — I'll post here again when the release is up: GitHub: https://github.com/ut-slayer/orangepi-4a-mainline Testers and feedback are very welcome. Thanks!
-
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.
