Boardcon_yang

Your debugging is already spot on — journald only stays on /run/log/journal until something runs journalctl --flush, and the fact that a manual flush works proves the storage side is fine. So this is purely an ordering problem: systemd-journal-flush.service runs early in boot, and on Armbian images /var/log.hdd is typically mounted by the armbian-ramlog machinery, which replaces /var/log with its tmpfs/overlay quite late compared to when the flush service expects a real /var/log/journal to exist. If the flush fires while ramlog hasn't finished restoring the /var/log/journal symlink into /var/log.hdd, it silently gives up and journald keeps the runtime journal open — exactly what you're seeing in /proc. You can confirm by comparing timestamps: systemctl status systemd-journal-flush.service versus armbian-ramlog (or mount time of /var/log.hdd). The clean fix is a drop-in for the flush unit, something like After=armbian-ramlog.service plus RequiresMountsFor=/var/log.hdd, so flush waits until the persistent path is actually there. Alternatively, an override on the ramlog unit adding Before=systemd-journal-flush.service achieves the same ordering from the other side. Either way the runtime journal gets flushed on the next boot instead of being stranded in /run until a manual flush.

The identical failure across two boards with nothing in common except the SD card is the tell here. RK3588S and H618 share no kernel, no GPU driver, no display stack — but they do share the first-boot procedure, and that's the most I/O-heavy moment in the whole process: the rootfs gets resized, SSH keys regenerate, caches build. One detail worth noticing: even the Minimal image "failed" on your Zero 3, and Minimal has no desktop to start — so what's hanging is likely the first-boot stage itself, not the desktop. A slow or counterfeit card dies exactly there. They often benchmark fine sequentially and crawl on the small random writes first boot does, so a "fast" card can still be the culprit. Give it a genuine 10-15 minutes watching the activity LED (regular bursts = still working; long dead silence = stuck), and if possible try a known-good name-brand card written with the imager's verify pass enabled. The working text console is your diagnostic window. When it stalls, log in from there and pull journalctl -b for the display manager and dmesg for the tail end — mmc I/O errors confirm the card theory, while a drm or GPU oops on the 6 Plus would point at the graphics side instead. Post those two outputs and the next step usually becomes obvious. Since other OSes run fine, the hardware is almost certainly healthy — this smells like media and first-boot timing rather than a board fault.

The old blaster isn't coming back on 26.04, and it's worth knowing why before chasing it: "odroid blaster" wasn't a lirc configuration, it was an out-of-tree Hardkernel module (lirc_odroid) built for the 3.10 vendor kernel, and hardware.conf died with lirc 0.10 anyway. There's no modern driver for that path, so the clean way is to rebuild the transmit side on the generic kernel infrastructure. Your LED circuit can stay exactly as it is. Declare a gpio-ir-tx node in a DT overlay on the GPIO behind pin 7 of the 40-pin header (Hardkernel's pinout will give you the GPIOX number), keep driving the LED through the same transistor/resistor from the 5V pin, and the TX side shows up as an extra /dev/lirc device. From there ir-ctl replaces irsend: capture the power code from your LG remote with any IR receiver (a $1 gpio-ir on a spare pin, or the onboard receiver if your image enables it) or pull the LG address/command from irdb, verify the LED blinks with a phone camera, then ir-ctl -S lg:: sends it. If you specifically want lircd and irsend back, modern lirc can sit on top of the same /dev/lirc0 — but for a single SEND_ONCE use case, ir-ctl alone is fewer moving parts. One gotcha: gpio-ir-tx is bit-banged, so a heavily loaded system can stretch the first transmission now and then — a repeat usually fixes it, that's not a config error.

Thanks for the detailed write-up — the 50.25 vs 74.25 MHz contrast is exactly the kind of data point the hdptx work needs. We've seen the same pattern on EM3588 (RK3588, dual HDMI 2.1, vendor 6.1): the PHY locks without complaint at standard clocks but gets flaky below ~75 MHz on some panels, which lines up with what the upstream phy-rockchip-samsung-hdptx series has been chasing around PLL and clock-ratio edge cases. The vendor kernel here clearly predates those fixes. Your EDID approach is also the practical answer for industrial displays. Most of the low-resolution panels we run into in signage and access-control products (1024x600, 800x480) sit right in that fragile clock range, and inflating blanking to reuse a known-good dclk keeps the native active area untouched — much cleaner than letting the scaler upscale. The initramfs gotcha you hit is worth repeating too: the connector asks for EDID well before the rootfs is up, so the override has to live in initramfs or it silently misses.

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.

Nice writeup — following this one closely, RK3576 boards are popping up everywhere lately. One thing worth mentioning: MiniLoaderAll.bin is fine for getting the vendor branch running, but for the mainline path you'll want the idbloader built from mainline U-Boot with the rkbin blobs instead. Armbian refreshed the bl31/bl32 and DDR blobs for RK3576 recently, so a mainline build is closer than it looks — the BL32 hang thread in this forum last month was exactly that stage. Once lubancat-3-v2 boots on vendor, it might be worth a quick try on the edge kernel to see what's still missing before submitting the board config upstream. Saves a round of review comments later. We do RK3576/RK3588 work on the industrial side at Boardcon, so if you run into anything odd during DDR init or PMIC sequencing, happy to compare notes.

Hi Avatar, You don't actually need U-Boot to understand Btrfs. Keep kernel + initrd + extlinux.conf on a small separate /boot (ext4 or ESP) and put only the rootfs on Btrfs subvolumes — booting a snapshot is then just a cmdline change: rootflags=subvol=@snapshots/42/snapshot. U-Boot loads the kernel from ext4 like everywhere else, the kernel mounts the snapshot. That's also why SUSE only needs their enhanced GRUB for convenience. For failure detection, U-Boot already ships the primitive: CONFIG_BOOTCOUNT_LIMIT with bootcmd/altbootcmd. Set fw_setenv upgrade_available 1 before an update, clear bootcount from a systemd oneshot at multi-user.target, and let altbootcmd boot the previous snapshot's extlinux label when bootcount exceeds BOOT_LIMIT. snapper pre/post snapshots, and the rest is just scripting around extlinux.conf — the grub-btrfs menu logic ports over nicely. One footgun to watch: /boot isn't captured by snapshots, so after a rollback make sure initrd/dtb still match the rolled-back kernel.

Nice find, Stefan — and thanks for including the LTSSM state, that makes the root cause unambiguous. LTSSM 0x3 is Detect.Quiet: the PHY never even starts link training because the PCIe rail never comes up. That is exactly what you expect when the regulator's enable GPIO points at a pin that does not drive the M.2 power switch.For anyone wondering how this happened: gpio0 RK_PC5 is a leftover from the Rockchip EVB reference design. The RK3588 EVB routes vcc3v3_pcie20's enable through GPIO0_C5, but the Orange Pi 5 board wires the M.2 power switch to GPIO2_A1. When a board DTS is derived from the EVB, the power-tree GPIOs are the first things to silently go wrong, because everything else (I2C, UART, display) still matches the silicon reference. A couple of points from the industrial/product side, since we maintain a DTS review checklist for our own RK3588 boards going through Armbian bring-up: 1. Cross-check enable GPIOs against the schematic, not against the SoC reference. The EVB-derived pins are the single most common source of "regulator never enables" bugs on Rockchip platforms. 2. While you are in there, check power sequencing too — not just the pin number. On designs where PERST# is also GPIO-controlled, the enable -> PERST# release -> link training order matters, and regulator-ramp-delay / startup-delay can mask or fix marginal boards. A rail that powers up in the wrong order can still enumerate NVMe but fail intermittently at cold boot. 3. Worth pushing the fix upstream: a local overlay is a fine workaround for your own board, but the wrong pin is still in the DTS shipped with mainline kernels (and it reproduced across 6.1.115 / 6.18.x / 7.1.8, so it is the shared DTS, not a kernel regression). A one-line patch to the board DTS would fix this for every user.

On the "intentional?" question: your mirroring experiment is the strongest evidence I have seen that RK3588 does not need the converge. If the layer_sel latch race existed on the rk3588 path,back-porting the rk3568 wait would either fix visible tearing or change timing observably. It did neither — inert, as you said.Combined with the masked cfg-done bits (BIT(vp->id) << 16) making each VP's done signal atomic, my working assumption is also "by design", and it would be interesting to hear from the Rockchip side whether the rk3588 path was deliberately simplified during bring-up.We reproduce the PD accounting pair on every mode change as well: [drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd6 [drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd5 On our side it is tied to VP enable/disable ordering during hotplug and dual-HDMI mode switching (EM3588: 2x HDMI 2.1 + DP 1.4 + 2x MIPI-DSI). One note for the industrial angle: in fanless enclosures we watch PD state indirectly through current draw, and these "unexpected power on" events make power telemetry look noisy even though the behaviour is benign. In our data the domains stay latched for a few ms and it does not move the thermal budget — but it would be worth quantifying if anyone is measuring per-domain power on RK3588. On the mainline relationship: since Ciocaltea's multi-output series restructured the cfg_done path, the BSP-only question stands. There is also a related thread on dri-devel where Igor Paunovic is scaling the VOP2 AXI clock (v2 series); in our on-list reply we noted that commit_tail ordering can affect power-domain handoffs on multi-CRTC configs. If that change lands, it may be worth re-testing whether the pd5/pd6 errors shift on the BSP side as well.

As Werner noted, the maintained project is edk2-porting/edk2-rockchip on GitHub: https://github.com/edk2-porting/edk2-rockchip Check the Releases page — the Orange Pi 5 family (RK3588S) builds are there. If there's no specific "5 Max" entry, the Orange Pi 5 build usually matches (same SoC variant), but verify the DDR init config covers your LPDDR5x bin. One thing worth noting: edk2-rockchip ships its own DTB, which can drift from the kernel DTB that Armbian provides. If you hit device-level quirks after switching (NPU, GPU, USB) that's usually the cause — the openSUSE MicroOS thread on this forum has a clean fix using sdbootutil DEVICETREE_SOURCE. Alternatively, Armbian 26.8 (just released) can build UEFI images as bootable Live ISOs, and the rewritten armbian-config installer can flash a bootloader directly to SPI. Worth considering if you're reinstalling anyway — you might not need a separate edk2 flash at all.

Hi thai hoang, Since this is console-only, one thing worth ruling out first: nothing may ever be requesting a mode on that connector at cold boot. status=connected just mirrors HPD — fbcon only sets a mode after the DRM hotplug path fires, which is exactly what your replug gives you. The standard test is to force it from the kernel cmdline: video=DP-1:1366x768e (the trailing e forces the connector enabled at boot, bypassing the hotplug dependency). If that lights the screen, you have the answer and the workaround in one — and modetest -s from libdrm-tests does the same from userspace if you'd rather test without a reboot. If it stays dark with e, then it's genuinely link training, and drm.debug=0x1e will show which side gives up (PHY training vs. cdn-dp firmware handshake). The early-boot dmesg lines (cdn-dp / tcpm / fusb302) would tell which case you're in — Werner's armbianmonitor covers it. On the unbind segfault — that's a real bug in cdn-dp's remove path, not just noise on your end. The driver doesn't tear down cleanly when the PHY/firmware is in a partial state. Worth reporting separately with the oops trace if you have it; either way, unbind isn't a safe reset on this driver.

Hi cu6apum, You already guessed right about the pre-DTB — armbianEnv.txt can't touch this stage. And since BL31 printed at all, DDR init in TPL/SPL succeeded, so it's the trust chain that's dying.On RK3576 that line usually means one of two things: 1. The trust image on flash has no OP-TEE payload (some vendor SDK builds are TEE-disabled), or one built for a different DRAM map — BL31 jumps, nothing answers, silence. 2. BL31 and BL32 aren't from the same rkbin build — happens when a vendor flash and an Armbian image each rewrote part of the chain. Maskrom + rkdeveloptool to dump what's actually on flash, then rewrite idbloader + uboot + trust as a matched set from the closest supported RK3576 board. If it turns out TEE-less, a no-TEE trust combo is a legitimate workaround — you lose the secure boot path but gain a booting board. Happy to compare notes if you post the full UART log.

Hi defcom5： Good catch on the layer-latch wait — that's exactly the kind of regression that bites in multi-CRTC industrial setups. We've been chasing a related symptom on EM3588 (RK3588J, fanless, dual HDMI 2.1 + DP 1.4): intermittent tearing when cycling between three-screen and single-screen configs, tracing to the same VOP2 commit path where the latch wait should gate the layer register write. Your register-level confirmation aligns with what we see — the scanout flip fires before the previous frame's latch settles. Worth noting: we're in a parallel thread on dri-devel (Igor Paunovic's VOP2 ACLK scaling series, v2 -> v3 pending) where the multi-CRTC commit path is also the stress point. Once our 48h soak data lands (60C ambient, ACLK 500 MHz vs. scaled), it should be directly comparable to your flicker findings — the same commit_tail path, different symptom surface. On Panfork being dead — for anyone running RK3588 in production deployments, this is probably the right moment to evaluate the Panthor/mainline route rather than staying locked into a vendor userspace that Mesa updates will keep breaking. The 4K@120 and NPU gaps you noted are real, but for industrial display workloads that don't need them, mainline is the safer long-term bet. We'll watch for your BSP PR and can cross-check on EM3588 if useful.

Our BSP engineer kicked off the SBC3568 Armbian SDK build (legacy BSP 5.10 branch via compile.sh, first time on this board), and we're hitting the usual first-build friction — dependency resolution, WSL2 environment quirks, and a few Rockchip-BSP-specific toolchain issues. Nothing show-stopping, just first-time setup pain. Realistic timeline: 3-4 working days to get a clean .debs set, which puts our data delivery at ~Aug 31 – Sep 2. I'd rather flag this now than go silent past the 48h mark and show up late with no heads-up. The two test angles you called out — 70°C sustained soak and the radio coex / NPU IOMMU group interaction — are exactly what we're building toward. We're not cutting scope, just the build took longer than estimated. Will post incremental progress as the build advances.

Hi nonconfigure, Short answer: yes, switching to the edge kernel is the right move, but here is what's actually going on so the fix is not mysterious next time. Why the 6.1 vendor kernel cannot drive the fan. The Rockchip 6.1 BSP ships its own thermal driver tree (`drivers/thermal/rockchip_thermal.c` under `/proc/vendor-thermal` paths) and its own PWM fan driver, but it does not expose the standard `pwm-fan`/`thermal` cooler bindings that the mainline/edge driver expects. So even if a board file declares a fan PWM and a trip point, the vendor kernel will not actually wire them together — the cooler's `cur_state` stays zero, the PWM stays at 0% duty, and the fan looks dead. That's why another 5 V fan on the same header behaves the same. Why edge kernel 6.19.6 fixes it. Mainline wired `pwm-fan` + `thermal` on the RK3588 about a year ago and the cooling-map bindings have been refined in edge since, including the `map0/map1/map2` node-name collision that defcom5 landed in Armbian 26.8 (PR #10514, merged Monday). After that fix, edge 6.19.6 on RK3588-class SoCs sees the cooler properly, and the trip points declared in the board DT become active. If the edge kernel doesn't pick it up either, the next thing to check is the DTB. The CM3588 FriendlyElec build carries a vendor DTB which references the 5 V header as plain GPIO, not PWM. You can confirm with `ls /sys/class/thermal/` and `ls /sys/class/pwm/` — if the cooler is missing or the PWM chip is absent, that's the symptom. The fix is to overlay a DTB fragment that exposes pwm0 (or whichever PWM channel is wired to the FAN header on the NAS carrier) and bind it to a cooler with trip points at 60°C / 75°C / 85°C. There are CM3588 community overlays floating around for this if your vendor kernel doesn't have one — let me know and I'll dig up links. A note from the other side of the same problem. We make an industrial RK3588 SBC (the EM3588) and we ship it fanless by design — the SoC + DRAM + PMIC envelope is rated for –40°C ~ +85°C at industrial temperature grades with a heatsink but no active cooling. In an enclosure at 30°C ambient the junction-to-ambient rise is what matters, not PWM. That's a different design trade from the CM3588 NAS form factor, but the engineering pattern is the same: most RK3588-class devices do not actually need a fan unless they're in a sealed box or running heavy NPU/GPU workloads continuously. If your case is open and the NAS is just acting as a NAS, you may be better off removing the fan entirely and letting the SoC thermally throttle on its own trip points, which the vendor kernel does correctly.

Hi iav, Thanks — taking your offer. We'll run release v2026.08.22 on a Boardcon SBC3568 (RK3568 SBC, 8 GB, Murata 1XD module for Wi-Fi, eMMC boot) tonight, using the README's standard path: install the kernel .debs, rocket.ko, and DT overlay, then patch in the GFP_DMA32 IOMMU fix from your `kernel-patches/` directory. We'll match your oracle — SHA-256 of the NPU output against the CPU reference for each of the seven layer-probe models plus mobilenet_v1 / v2 / resnet18, with the result captured at 800 MHz via SCMI (your `scmi_rate=800000000` module parameter) and DVFS pinned. Specifically we want to cover three angles that ODROID-M1 doesn't quite match — eight-GiB usable memory above 4 GiB, the Murata radio coex path that shares an IOMMU group with the NPU on this board, and a long-running thermally-constrained soak at 70°C ambient rather than room temperature. The last one is what we do all the time here, so it falls out for free. Will post back in 48 h with: - the per-model SHA-256s and timings - top-5 match against the CPU reference - one-hour therm soak log (CPU/NPU temperature traces + NPU clock held at 800 MHz via SCMI despite thermal pressure — the same bit-identity check you ran at room temperature) If results hold, would you like us to add the report as a Tested-by line in your v2026.08.22 README, or are you sending that as a separate Mesa branch PR?

Hi Igor, Both, sequenced, works for us — thanks for laying it out clearly. So that the BSP run is reproducible for anyone reading the v3 cover letter, here is the configuration we will use: 。Board: EM3588 (RK3588J, fanless industrial chassis, ambient held at 57 C). 。Kernel: Rockchip BSP 6.1 LTS with v2 backported (re-verified against v3 when it lands). 。Display load: dual HDMI 2.1 + DP 1.4 active simultaneously, with periodic reconfigure cycling. between three-screen and single-screen to exercise the multi-CRTC commit path. 。Duration: 48hs. 。Logging: tsadc junction temperature sampled every 10 s, ACLK frequency, and thermal throttling events. 。Comparison: patch vs. no-patch baseline at the same display load (ACLK 500 MHz fixed vs. scaled). We expect numbers within the week. If v3 drops before the run finishes, I will follow up on the thread with the data — that also lines up with the on-list summary I promised. On the mainline clean-room run: DTS bring-up for our board is in progress, and it is the next work item after the soak. I would rathernot put a hard date on it, but when it is ready I will run v3 against drm-misc-next as you described and attach the Tested-by to that tree. One thing we want to get right in the comparison runs: you mentioned the HDMI FRL path holds ACLK at 750 MHz independently on your board. Should we treat that as expected behavior to document, or is it still an open question in the clock parent/rate selection? Either answer changes how we bucket the thermal data between the HDMI and DP paths,since our load crosses both. Good luck with v3.

We ran into both of these bringing up UFS on our own RK3576 boards — they're separate problems: Stuck at initramfs: nine times out of ten the root= device name didn't follow the move. Drop to the busybox prompt and check cat /proc/cmdline — if root= still points at /dev/mmcblk... while the UFS shows up as /dev/sda1, the kernel simply can't find the rootfs. Fix is a one-liner in /boot/armbianEnv.txt (or the U-Boot env). If U-Boot gets far enough to hand off to initramfs, the loader itself is fine, so don't re-flash anything yet. "No bootable install method ... no board u-boot support": that message comes from the armbian-install board database — NanoPi M5 isn't wired up for a UFS write target yet (SD/eMMC paths exist, UFS doesn't). Copying the SD install won't work until that's added. The workaround is manual: dd idbloader/u-boot.itb to the UFS at the correct offsets for RK3576 (the loader layout on UFS differs from eMMC, so don't reuse eMMC offsets). One caution on RKDevTool: erasing from it doesn't always clear the RK private header/IDB residue, which can leave a half-valid parameter block that confuses a later install. rkdeveloptool with an explicit erase 0x0 of the first blocks is more reliable. Try the armbianEnv.txt root= fix first — it's the cheap one and probably gets you booting.

The 13× MobileNet V1 number matches what we see on RK3588 at the same clock — good to see it confirmed on RK3568 too. Two small things worth checking before the mesa branch goes anywhere: 1. PC_TASK_CON.task_number is 8-bit on RK3568 vs 12-bit on RK3588. Make sure the rocket driver masks it, or commands above 255 truncate silently. 2. If you're claiming bit-identical results, pin the DVFS point and CMA region first — the same model can drift across boards otherwise, and this starts to matter more once RK3576 DVFS lands upstream. We have RK3568 boards here (SBC3568) and can run the same MobileNet V1/V2 + sha256 oracle for comparison if useful. Do you plan to send the mesa branch upstream, or keep it downstream for now?

Hi NEO, Great write-up — the LIBVA_DRIVER_NAME=rockchip wrapper to bypass Chrome's sandbox detection is the one detail most tutorials miss. We run the same stack on Boardcon EM3588 (industrial RK3588 SBC), a few production-side notes: CMA headroom for multi-stream. Default cma=128M chokes on 2+ concurrent 1080p decode streams. We set cma=256M and check cat /proc/meminfo | grep -i cma before chasing driver bugs — silent MPP_ERR_ALLOC fall-back to software decode is a pain to diagnose. 4K@120Hz flicker — RGA2→RGA3 handoff race, not GPU or VPU. We tracked the same symptom to RGA2 (scaling) being reused while the previous RGA3 (composition) job was still in flight. Your "drop to 60Hz" fix is right; just adding the root cause so others don't reach for --disable-gpu-compositing (which, per your note #9, silently kills hardware decode). Industrial 24/7 thermal is a different curve. Desktop 50-60°C translates to sustained 65-70°C on a fanless enclosure at 30°C ambient. VPU is fine; the SoC cluster throttles first. Anyone running your stack in a sealed chassis needs PWM fan tied to tsadc at ~75°C. Happy to run your woodyst+PR#2 driver on EM3588 and give you a second-hardware Tested-by — what's your preferred off-forum channel for coordination?

Solid write-up from iDare. Two things worth adding from a vendor perspective, since we shiped RK3588 boards and hit this failure mode in the field: 1. The gpu-supply fix is board-specific. vdd_gpu_s0 exists on the OPi5 Plus. On other RK3588 boards the GPU rail is fed by a different regulator (some use a PWM-controlled DC-DC), so check your own DTS before copying the overlay - a wrong phandle either fails the DTB build or still panics at panthor probe because the regulator never gets enabled. 2. For anyone deploying fleets (signage, kiosks, industrial), treat this as a fleet-management problem, not a recovery problem. One unattended apt upgrade bricking a rack of displays overnight is the kind of thing that kills a project. On our production images we apt-mark hold the kernel packages and only roll kernel updates through a controlled test gate - the panthor overlay update is exactly that class of change. If you stay on 6.1.75 + custom overlay, also check regulator-enable-ramp-delay on the GPU rail; some boards need it to avoid transient SErrors under load even with gpu-supply present. Mainline 6.15+ (f94500eb7328) had fixed; the overlay keeps deployed fleets running in the meantime.

Great work putting this together — the mpp→vaapi bridge is the piece most people skip, and having it in a PPA with a patched gnome-remote-desktop for hardware H.264 encode is genuinely useful for anyone running RK3588 headless over RDP. We use RK3588 in industrial digital signage and edge devices , and the MPP + RGA pipeline you've packaged here is essentially the same stack we rely on for multi-stream hardware decode in commercial displays. A couple of observations from production: 1. CMA allocation: If you're running multiple concurrent decode sessions (e.g., 3+ 1080p streams), the default CMA size on the Armbian Ubuntu image may not be enough. We typically set cma=256M (or higher for 4K decode). Worth checking cat /proc/meminfo | grep Cma if you hit MPP_ERR_ALLOC under load. 2. RDP encode bitrate: For the gnome-remote-desktop h264_rkmpp path, have you experimented with bitrate/quality settings? In our remote maintenance scenarios, dropping to 4 Mbps with -b:v 4M gives a good balance between visual quality and thermal headroom on fanless enclosures. One question: have you tested the vaapi bridge with Firefox as well, or only Chrome? Firefox's VA-API path (media.ffmpeg.vaapi.enabled) can be picky about the driver reporting format. Thanks for sharing the PPA — this fills a real gap while Armbian sorts out the Rock 5B image situation.