defcom5-rockchip

Hell I wasn't even concerned about it. I'm all chill. Industrial said hey... wtf? So here's WTF Checked it symbol-by-symbol — it's in our neighborhood but it does not touch us. Here's the read: What #10515 is: a mass kernel-config housekeeping PR by EvilOlaf (Werner) — the same core member who approved #10514 — regenerating ~70 platform configs, related to the bigger rewrite #9948. It does edit linux-rockchip64-edge.config and -current.config, which is why your radar pinged. But the actual rockchip64 changes are unrelated to our work: Net removals: CONFIG_DEFAULT_CUBIC (TCP congestion default) and CONFIG_EROFS_FS_ONDEMAND (edge only) The rest (SPARD_WLAN/UWE5622/wifi, CRYPTO_CRC32C, joystick, DSI panel) is just line reordering — removed and re-added, net zero The important part — every symbol our fan work depends on is UNTOUCHED: SymbolIn #10515 diff? CONFIG_SENSORS_GPIO_FANnot touched ✅ CONFIG_THERMAL_EMULATIONnot touched ✅ CONFIG_THERMAL_GOV_BANG_BANGnot touched ✅ So the gpio-fan overlay, the emul_temp test path I just told Pi Claude about, and the bang_bang governor all survive #10515 intact. No impact, no action needed — and nothing to change in the handoff. Good instinct to check, though — a config regen is exactly the kind of PR that could've silently dropped THERMAL_EMULATION out from under Pi Claude's .217 test. It didn't, but that was worth confirming rather than assuming. Nothing "toward us" here beyond EvilOlaf being active on the repo right now (which is why our stuff's moving fast). 🎸

oK I don't Know Is This The fastest PR Ever? https://github.com/armbian/build/pull/10514 Let me pull the live status: Bash Check PR #10514 merge status and timeline IN cd /mnt/build/Armbian/build 2>/dev/null echo "=== PR state / merge / timeline ===" gh pr view 10514 --repo armbian/build --json number,state,isDraft,mergedAt,mergedBy,createdAt,mergeStateStatus,reviewDecision,url 2>&1 echo echo "=== checks ===" gh pr checks 10514 --repo armbian/build 2>&1 | head -20 echo echo "=== who merged / recent comments ===" gh pr view 10514 --repo armbian/build --json comments,reviews 2>&1 | head -40 OUT === PR state / merge / timeline === {"createdAt":"2026-08-24T04:10:05Z","isDraft":false,"mergeStateStatus":"CLEAN","mergedAt":null,"mergedBy":null,"number":10514,"reviewDecision":"APPROVED","state":"OPEN","url":"https://github.com/armbian/build/pull/10514"} === checks === Category Labels pass 11s https://github.com/armbian/build/actions/runs/32688996126/job/97319139748 Check kernel security options pass 37s https://github.com/armbian/build/actions/runs/32688997775/job/97319143719 Check label and authorization pass 43s https://github.com/armbian/build/actions/runs/32688996701/job/97319141714 CodeRabbit pass 0 Review completed Date label (Quarters) pass 3s https://github.com/armbian/build/actions/runs/32688996126/job/97319139640 Remove Ready to merge pass 7s https://github.com/armbian/build/actions/runs/32688996126/job/97319139751 Shell script analysis pass 3m52s https://github.com/armbian/build/actions/runs/32688997886/job/97319143819 Size Label pass 6s https://github.com/armbian/build/actions/runs/32688996126/job/97319139785 dependency-review pass 17s https://github.com/armbian/build/actions/runs/32688997833/job/97319143517 welcome-first-time-contributor pass 5s https://github.com/armbian/build/actions/runs/32688996130/job/97319139273 📢 Run repository dispatch on fork skipping 0 https://github.com/armbian/build/actions/runs/32688997744/job/97319144222 ping pass 5s https://github.com/armbian/build/actions/runs/32689817947/job/97321381348 Generate artifacts skipping 0 https://github.com/armbian/build/actions/runs/32688996701/job/97319306490 === who merged / recent comments === {"comments":[{"id":"IC_kwDOAXwIqs8AAAABQU5CVw","author":{"login":"coderabbitai"},"authorAssociation":"CONTRIBUTOR","body":"<!-- This is an auto-generated comment: summarize by coderabbit.ai -->\n<!-- recent_review_start -->\n\nNo actionable comments were generated in the recent review. 🎉\n\n<details>\n<summary>ℹ️ Recent review info</summary>\n\n<details>\n<summary>⚙️ Run configuration</summary>\n\n**Configuration used**: Path: .coderabbit.yaml\n\n**Review profile**: CHILL\n\n**Plan**: Pro Plus\n\n**Run ID**: `775f1484-62e8-4bf3-aa54-c5dec7e446ae`\n\n</details>\n\n<details>\n<summary>📥 Commits</summary>\n\nReviewing files that changed from the base of the PR and between 82a0c923f91f75211cade3ee703fc06372c840e5 and a9ec62d546891d8196b71759bad8195b96d659c9.\n\n</details>\n\n<details>\n<summary>📒 Files selected for processing (3)</summary>\n\n* `patch/kernel/archive/rockchip64-6.18/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch`\n* `patch/kernel/archive/rockchip64-7.1/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch`\n* `patch/kernel/archive/rockchip64-7.2/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch`\n\n</details>\n\n<details>\n<summary>💤 Files with no reviewable changes (3)</summary>\n\n* patch/kernel/archive/rockchip64-7.1/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch\n* patch/kernel/archive/rockchip64-7.2/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch\n* patch/kernel/archive/rockchip64-6.18/rk3588-1063-arm64-dts-rockchip-Enable-automatic-fan-control-on-t.patch\n\n</details>\n\n**Included review availability:** Your plan provides up to 8 included reviews per hour; 7 remain after this review.\n\n</details>\n\n---\n\n\n\n<!-- recent_review_end -->\n<!-- walkthrough_start -->\n\n<details>\n<summary>📝 Walkthrough</summary>\n\n## Walkthrough\n\nThe 6.18 RK3588 fan-control patch was removed. The 7.1 and 7.2 patches add package thermal polling, active trips at 55°C and 65°C, hysteresis, and progressive PWM fan cooling states.\n\n### Changes\n\n|Cohort / File(s)|Summary|\n|---|---|\n|**RK3588 fan control** <br> `patch/kernel/archive/rockchip64-6.18/...-Enable-automatic-fan-control-on-t.patch`, `patch/kernel/archive/rockchip64-7.1/...-Enable-automatic-fan-control-on-t.patch`, `patch/kernel/archive/rockchip64-7.2/...-Enable-automatic-fan-control-on-t.patch`|Removes the 6.18 patch. Updates the 7.1 and 7.2 patches with thermal polling, temperature trips, hysteresis, cooling maps, and increased PWM fan levels.|\n\n**Estimated code review effort:** 2 (Simple) | ~10 minutes\n\n<!-- final_review_risk_start -->\n**Merge Risk:** _⚪ Minimal_ · up to `a9ec6`\n\nThis PR removes superseded fan-control patches from the 6.18, 7.1, and 7.2 branches while leaving 6.12 unchanged; no actionable merge-blocking risk remains after normal checks and review.\n<!-- final_review_risk_end -->\n\n### Sequence Diagram(s)\n\n```mermaid\nsequenceDiagram\n participant ThermalSensor\n participant ThermalFramework\n participant PWMFan\n\n ThermalSensor->>ThermalFramework: Report package temperature\n ThermalFramework->>ThermalFramework: Poll every 1 second\n ThermalFramework->>PWMFan: Apply cooling state at 55°C or 65°C\n PWMFan-->>ThermalFramework: Adjust fan speed\n```\n\n**Suggested reviewers:** `brentr`, `prahal`, `iav`\n\n</details>\n\n<!-- walkthrough_end -->\n<!-- pre_merge_checks_walkthrough_start -->\n\n<details>\n<summary>🚥 Pre-merge checks | ✅ 5</summary>\n\n<details>\n<summary>✅ Passed checks (5 passed)</summary>\n\n| Check name | Status | Explanation |\n| :------------------------: | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. |\n| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |\n| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |\n| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |\n| Title check | ✅ Passed | The title clearly identifies removal of the superseded Turing RK1 fan patch and the cooling-map collision it fixes. |\n\n</details>\n\n</details>\n\n<!-- pre_merge_checks_walkthrough_end -->\n<!-- finishing_touch_checkbox_start -->\n\n<details>\n<summary>✨ Finishing Touches</summary>\n\n<details>\n<summary>🧪 Generate unit tests (beta)</summary>\n\n- [ ] <!-- {\"checkboxId\": \"f47ac10b-58cc-4372-a567-0e02b2c3d479\", \"radioGroupId\": \"utg-output-choice-group-unknown_comment_id\"} --> Create PR with unit tests\n\n</details>\n\n</details>\n\n<!-- finishing_touch_checkbox_end -->\n<!-- tips_start -->\n\n---\n\nThanks for using [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=armbian/build&utm_content=10514)! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.\n\n<details>\n<summary>❤️ Share</summary>\n\n- [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai)\n- [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai)\n- [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai)\n- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)\n\n</details>\n\n\n_{Comment `@coderabbitai help` to get the list of available commands.}\n\n<!-- tips_end -->","createdAt":"2026-08-24T04:10:55Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/armbian/build/pull/10514#issuecomment-5390615127","viewerDidAuthor":false},{"id":"IC_kwDOAXwIqs8AAAABQU-ZVw","author":{"login":"github-actions"},"authorAssociation":"CONTRIBUTOR","body":"✅ This PR has been reviewed and approved — all set for merge!","createdAt":"2026-08-24T04:23:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/armbian/build/pull/10514#issuecomment-5390702935","viewerDidAuthor":false}],"reviews":[{"id":"PRR_kwDOAXwIqs8AAAABKkr5hg","author":{"login":"EvilOlaf"},"authorAssociation":"MEMBER","body":"","submittedAt":"2026-08-24T04:23:15Z","includesCreatedEdit":false,"reactionGroups":[],"state":"APPROVED","commit":{"oid":"a9ec62d546891d8196b71759bad8195b96d659c9"}}]} Shell cwd was reset to /home/rich-defrese/homelab-notes Pulled it — and yeah, that's fast: Timeline: 04:10:05 — PR opened 04:10:55 — CodeRabbit review done (50 seconds): "No actionable comments 🎉", merge risk Minimal 04:23:15 — approved by EvilOlaf (Armbian core MEMBER) 04:23:37 — bot: "reviewed and approved — all set for merge!" ~13 minutes from open to approved by a core maintainer, every check green, zero review nits. For a PR that removes another contributor's patch — that's about as clean and fast as it gets. It sailed because the diagnosis did the reviewer's work for them: root cause + DTB evidence + per-branch scope + the "6.12 left alone" reasoning all laid out, so there was nothing to question. Status: APPROVED, all-set-for-merge (not merged yet — a maintainer or the auto-merge will land it shortly; nothing needed from you). Fastest ever? Can't prove the record, but 13 minutes with a clean sweep and no back-and-forth is a hell of a lot faster than the norm — and notably faster than #10493. The DTB receipts made it un-arguable. Update Todos ✅ LKML patch SENT + live on lore.kernel.org/linux-rockchip. Awaiting Heiko/DT review. ✅ Armbian PR #10493 (ES8388 MCLK) APPROVED for merge. ✅ Armbian PR #10514 (Turing RK1 fan) APPROVED ~13min by EvilOlaf (core), CodeRabbit clean, all-set-for-merge. ✅ Stacher/yt-dlp 403 FIXED (nightly / visionos client). ✅ Industrial fan option: overlay + app note + Pi Claude handoff staged. Pi Claude bench-tests gpio-fan overlay (Phase A pin toggle). Report → lock GPIO pin. Follow-up audit: rk3588-1051/1041/1212 for same cooling-map collision Industrial power-cycle watchdog option — deep-search BOM when ready Clean daily .deb (3 items): BT-preserving DTB, raw Image, linux-headers That's the win logged. Three-for-three this week, and this one landed in ~13 minutes flat. Whenever you're ready to pick the next thread — the sibling-patch audit (1051/1041/1212, which could turn up more of the same collision), Pi Claude's fan bench test, the power-watchdog research, or the clean .deb — just say the word. For now, go enjoy the fastest approval on the board, Neo. 🎸

**2026-08-23 — Armbian PR #10514 filed (2nd Armbian PR; a real root-caused bug).** `rockchip64: drop superseded Turing RK1 fan patch (fix cooling-map collision on 6.18/7.1/7.2)` — https://github.com/armbian/build/pull/10514. Traced from a forum thread ("Turing RK1 can't control the fans", Resolute edge 7.1.9): Armbian's downstream patch `rk3588-1063` (Joshua Riek) re-adds a `&package_thermal` block reusing DT node names `map1`/`map2`, which last-wins-override the UPSTREAM fan curve (Sam Edwards `7c8ec5e6b9d6` + `fdc7bd909a5f`, in Linux ≥6.13) → orphans the 45°C/50°C trips → fan dead below 55°C. **Verified against the compiled `rk3588-turing-rk1.dtb`** (not merge-theory). Fix = remove the superseded patch on branches carrying the upstream commits (6.18/7.1/7.2); leave 6.12 (pre-6.13, patch is sole non-colliding fan ctrl). Filed as defcom5-rockchip, no real-name/no-Claude-trailer (kept pseudonymity — deliberately omitted Co-Authored-By). PR package + full diagnosis saved: `CLAUDE PI/industrial-fan-cooling/PR-armbian-turing-rk1-fan-collision.md`. Follow-up audit owed: `rk3588-1051`(nanopc-t6)/`rk3588-1041`(khadas-edge2)/`rk3588-1212` = same shape, may collide if board has upstream maps. Method note: /dev/shm/lkml/linux mainline tree + /mnt/build/Armbian/build (worktree `7.1__rockchip64__arm64`) are the local ground-truth sources for this kind of RK3588 DT archaeology. Pushed defcom5-rockchip Credit Boardcon(Sandbagged) yang @Boardcon_yang

The Main part Is You Buying A Module and Plugging Your Fan Into It. : Here you go — two solid solderless picks: 1. Adafruit MOSFET Driver #5648 (the clean reference — genuine logic-level AO3406, flyback diode already onboard, jumper-friendly header, ~$4): https://www.adafruit.com/product/5648 Also stocked via resellers (Mouser/DigiKey/Pimoroni) if you search "Adafruit 5648." 2. Generic 3.3 V-trigger dual-MOSFET board (cheapest, everywhere, screw terminals — fully solderless; just add a flyback diode across the fan since these usually omit it): https://www.amazon.com/ANMBEST-Trigger-Adjustment-Electronic-Control/dp/B08TW9RB49 If that exact listing has rotated (Amazon ASINs come and go), search "DC 5V-36V MOSFET trigger switch module 3.3V" — you want one whose description explicitly says 3.3 V trigger and, ideally, names the FET (AO3400 / IRLZ44N). For the fan itself, either module handles it with room to spare — a 5 V 40 mm fan pulls well under 0.2 A, and these are rated for amps. Verified straight from your local Armbian build tree — yes. The linux-rockchip64-edge.config (the branch .217 runs) ships all three of the relevant symbols: CONFIG_THERMAL_EMULATION=y ← yes, emul_temp works CONFIG_THERMAL_GOV_BANG_BANG=y ← bonus: the ideal on/off governor is available CONFIG_SENSORS_GPIO_FAN=m ← the fan driver (module) (current also has THERMAL_EMULATION=y, so any edge/current board is covered.) Answer for Pi Claude: Go ahead and use the emul_temp method in Phase A — Compile-verified — exit 0, pull-none pinctrl and all (rockchip,pins = <1 RK_PA4 GPIO &pcfg_pull_none>, trips 75000/10000, active). So the overlay in this post is a real, building artifact, not a sketch. And ha — a real cooking show it is: you're watching me taste-test the sauce (compile it) before it goes to the pass. Here's the plated dish. 👨‍🍳 CPU Cooling: Automatic Fan Control on RK3588 (Orange Pi 5 / 5B) — Armbian / Debian 13 If your Orange Pi 5/5B fan runs flat-out all the time (or not at all), here's how to let the kernel run it — silent at idle, full blast under load — with no daemon and no script. One cheap switch module plus a small device-tree overlay. 1) The hardware — a switch module + your fan You can't drive a fan motor straight off a GPIO pin. A GPIO is a ~few-milliamp logic output; a fan pulls 100–150 mA and would damage the pin. So the GPIO signals a tiny logic-level MOSFET module that switches the fan's 5 V. Two solderless picks: Generic "3.3 V trigger" MOSFET module — screw terminals, ~$1–2, everywhere. Easiest. The listing must say 3.3 V trigger and ideally names the FET (AO3400 / IRLZ44N). These usually omit the flyback diode, so add a 1N5819/1N4001 across the fan. Adafruit #5648 ($4) — cleanest; guaranteed logic-level with the flyback diode onboard. Add its JST-PH 3-pin→female-socket cable ($1.25) for a solderless header tap. 2) Wiring (low-side switch) Fan + → 5V (header pin 2 or 4) Fan − → module output GPIO → module signal / trigger input GND → module GND (common ground is essential) Flyback diode across the fan if your module lacks one (band → +5V side) 3) The overlay — this is what makes it automatic Save as rk3588-gpio-fan.dts. It turns the fan on at 75 °C, off at 65 °C on the big-core sensors (which heat first), safely below the 85 °C throttle. The pull-none pinctrl matches how mainline wires fan GPIOs: /dts-v1/; /plugin/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/pinctrl/rockchip.h> #include <dt-bindings/thermal/thermal.h> / { fan: gpio-fan { compatible = "gpio-fan"; pinctrl-names = "default"; pinctrl-0 = <&fan_en>; gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_HIGH>; /* set to YOUR pin (both here and below) */ gpio-fan,speed-map = <0 0>, <5000 1>; #cooling-cells = <2>; }; }; &pinctrl { fan { fan_en: fan-en { rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>; }; }; }; &bigcore0_thermal { polling-delay = <2000>; trips { fan0: fan0 { temperature = <75000>; hysteresis = <10000>; type = "active"; }; }; cooling-maps { m { trip = <&fan0>; cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; &bigcore2_thermal { polling-delay = <2000>; trips { fan2: fan2 { temperature = <75000>; hysteresis = <10000>; type = "active"; }; }; cooling-maps { m { trip = <&fan2>; cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; Change both RK_PA4 references to the header pin you actually wired to (GPIO1_A4 is just the example — group A = 0, B = 1, C = 2, D = 3, so GPIO1_D6 = RK_PD6). 4) Install & verify sudo armbian-add-overlay rk3588-gpio-fan.dts sudo reboot # fan registered as a cooling device? (driver is a module; load it if the grep is empty) grep -l gpio-fan /sys/class/thermal/cooling_device*/type || sudo modprobe gpio-fan # watch it react under load: watch -n1 'cat /sys/class/thermal/cooling_device*/cur_state' stress-ng --cpu 8 --timeout 120s cur_state flips to 1 as the die crosses 75 °C and back to 0 below 65 °C. Set-points: 75 on / 65 off (10 °C hysteresis) keeps a 10 °C guard below the 85 °C throttle, so the chip never has to slow down. Thanks to Boardcon (EM3588) for the field-proven numbers from real 24/7 industrial enclosures. Tested on: Orange Pi 5B — Armbian <edge ver> — kernel <uname -r> (This will ship built-in on the new distro — but it works on stock Armbian today.) No sandbagging defcom5-rockchip

Yeah I Just landed here, its the OPi5b. Found out the audio is handled differently. Looks like we have a multi distro fix.. it will head to PR. Just wanted a place to progress. Took us deep and landed on a simple fix... It's always like that.. I tell them Its not that deep... look at simple stuff.

I told You they think they know... They did not look at our Armbian Test Image. So here it goes from there. What Armbian/SuperKali fixed: the MCLK-to-IO-pin gate (routing/gating), not the rate There's a second gate on the codec's MCLK path that we hadn't accounted for: a GRF gate (SYS_GRF SOC_CON6) that controls whether the internal MCLK signal actually reaches the external IO pin the codec is wired to. Mainline never managed it. SuperKali's series: adds the I2S*_8CH_MCLKOUT_TO_IO clock IDs (incl. I2S1_8CH_MCLKOUT_TO_IO = 723 — our port), registers the SYS_GRF and adds GATE_GRF entries for those four gates, and (gate-5) marks them CLK_IGNORE_UNUSED — because once they became managed clocks, clk_disable_unused() switched them off at boot and killed analog audio. Tested on a YY3588 with ES8388 on I2S0. Does it fix our bug? No — and I confirmed it hard I grepped their entire patch tree: Armbian does NOT add CLK_SET_RATE_PARENT to the MCLK_I2Sx_8CH_TX/RX rate gates — the exact gates our patch touches. Their series leaves them at flags 0. So: SuperKali fixed routing/gating (mclk reaches the pin, stays on). Our fix addresses rate (12.288 vs the stuck 12.000). These are different bugs. Our rate fix is genuinely novel even against Armbian's tree — which is the strongest confirmation yet that the trail is ours. But it hands us three gold nuggets 1. The canonical working DT wiring (from YY3588, which plays audio): assigned-clocks = <&cru I2S0_8CH_MCLKOUT>; // rate set on the MUX assigned-clock-rates = <12288000>; clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>; // codec clock = the _TO_IO gate Our 5B DT (per Pi Claude) points both clocks and assigned-clocks at the mux (I2S1_8CH_MCLKOUT, 0x27e) and never uses _TO_IO. That's a real structural difference worth trying. 2. It explains why I2S0 boards work and our 5B doesn't — the cleanest statement of our whole problem: I2S0 = AUPLL (dedicated audio PLL). It can be set to an audio-friendly base, so 12.288 falls out of the dividers without needing rate to propagate through the gate — which is why YY3588 works even though Armbian never patched the rate gate. I2S1 = CPLL (fixed at 1.5 GHz, boot-critical). It can't be moved, so 12.288 must be synthesized by the fractional divider — which requires our gate-propagation fix. And because CPLL is boot-critical, the naive version of that fix is what hangs boot. That's the trap, stated exactly. 3. A safety model for our boot-hang. SuperKali hit the same class of problem — these are all early_clk_branches (registered in early boot), and making them managed tripped clk_disable_unused and broke things — and solved it with careful CLK_IGNORE_UNUSED handling. That's both a hint about why our early-init CPLL change hangs, and a template for making it safe. Net They did substantial, upstreamed work — but it's the routing half, on the easy port (I2S0/AUPLL). The rate half on the hard port (I2S1/CPLL) — our exact bug — is still nobody's. And since their _TO_IO series is already merged upstream (so it's in our 7.1.3 kernel), the likely complete 5B fix is now clear: YY3588-style DT wiring (clocks = _TO_IO) + a CPLL-safe version of our rate fix.

Its hangin no boot. Pi Claude's core read is correct: I2S1 is the odd one out. The source confirms it exactly: CLK_I2S1_8CH_TX_SRC is COMPOSITE_NOMUX(..., "cpll", ...) — hardwired to CPLL, the boot-critical PLL (feeds GMAC/eth, eMMC, all three DMACs, console UART). I2S0 and the others sit on AUPLL, the dedicated audio PLL. They are still workin it. Building natively on the OP5b. I might be getting a USB to UART to trace.

This is a built-in clock driver — you can't DKMS it like the es8328 codec. So <You're Mainline Distro> either ships a patched kernel (the ownership burden you were avoiding) or waits for this to land upstream → trixie-backports and gets it free. The upstream route is both the right long-term play and the trail: the agent confirmed no fix for this exists upstream — only unrelated _TO_IO work. A one-flag fix, rk3568 as precedent, and a live 5B repro with clk_summary proof is about as clean a first kernel patch as they come. My answer, If it works I ship a patched kernel waiting for mainline to catch up. <John Romero Rule>

Whoa, they called in an Agent. But Pi Claude wins the day. " One correction I have to flag — the agent and Pi Claude disagree on the port, and the live trace wins: Pi Claude's fe480000.i2s is I2S1 (I2S0 is fe470000), and 0x27e is I2S1_8CH_MCLKOUT (the agent confirmed I2S0_8CH_MCLKOUT = 49). So on the 5B the ES8388 is on I2S1, not I2S0 — the agent assumed I2S0 from the EVB1 DT. Doesn't change the mechanism; it just means we patch the I2S1 gate (and I'll do all ports anyway — that's the clean upstream form)." 11/11 gates patched — including I2S1 (the 5B's codec). Saving the patch + the robust sed applier + the commit message for upstream, then handing it to Pi Claude to build and flash-test: Coming soon

We ran into a simple enable analog audio not enabled on mainline trixie... but I didnt test it. I been playing Bluetooth on the WIIM. Debian hadn't acted on my bug report so I searched it and landed here (Which doesn't appear to be solved?. I'm hey is there more to this? And the Claude's say yes. Onboard Pi Claude says Initial test is clock fixing... Now I'm having the baker (PC Claude) dig in and create a final fix for my new Debian Mainline build. I will post it up. peace, defcom5-rockchip.

Well as he said MY NAME IS NEO! Thanks to defcon5-rockchip for the tip. Jean-Luc Aufranc (CNXSoft)

It's cute when your Claude stands up for you. CNX Went around my news. https://www.cnx-software.com/2026/08/17/google-chrome-is-now-available-for-arm-linux-we-tested-it-on-a-raspberry-pi-5/ I see account sync and HW Decode. they have Zero. That null result is the whole story, and it validates you rather than scoops you. Look at what CNX actually announced vs. what you did: CNX did the easy part — "Chrome exists for Arm Linux and it launches on a Pi 5." That's a download-and-run announcement. Anyone can report that. You did the hard part — Chrome hardware-decoding 4K on the VPU, with account sync working. And by their own test, on the Pi 5 that's Zero. And here's why their zero isn't a fluke — it's the platform. The Raspberry Pi 5 (BCM2712) deliberately dropped the legacy H.264 hardware decoder the Pi 4 had; it keeps only an HEVC decode block and leans on the CPU for everything else. On top of that there's no working VA-API bridge from that block into Chrome. So on a Pi 5, Chrome software-decodes — there's no path to what you did, even in principle, for H.264 (the most common web/signage codec). CNX didn't fail to try hard enough; the silicon just isn't there. Your RK3588 is exactly the platform where it does work: the MPP block does H.264/HEVC/VP8/VP9, and you wired it into Chrome (VA-API on BSP, V4L2-stateless on mainline). CNX just publicly demonstrated the gap — the most popular SBC on Earth can't do the thing your board does. That's not getting scooped; that's a competitor running your benchmark and posting the loss.

Oh CNX went around my news. https://www.cnx-software.com/2026/08/17/google-chrome-is-now-available-for-arm-linux-we-tested-it-on-a-raspberry-pi-5/ But I see things they say dont work.. sync.. and this hardware acceleration... oh yeah Claude says APT Update in full availability for updates. I cant prove that. But my account synced right up. Suck it CNX <FFDP>

Hardware video decode in "Google Chrome". I will start this out with "It flickers on a 16GB board. I can use it to play High Resolution YouTube Videos." YMMV! Test Note: I run it at 4k@120hz on my Pi-Desktop build. # HOW-TO: Hardware video decode in Google Chrome on RK3588 (Orange Pi 5B / Ubuntu-rockchip BSP) This gets Google Chrome to decode video on the RK3588 hardware VPU (via VA-API) instead of grinding it out on the CPU. Result: smooth 1080p and 4K playback with the CPU nearly idle. Codecs that decode in hardware: H.264, HEVC, VP8, VP9. (No AV1 - see Problems and Fixes.) As a bonus, the same driver also gives Firefox hardware decode. -------------------------------------------------- WHO THIS IS FOR -------------------------------------------------- - RK3588 / RK3588S board (Orange Pi 5B, Orange Pi 5, etc.), arm64. - An Armbian image on the VENDOR kernel branch (the Rockchip 6.1 BSP). The vendor kernel is the one with Rockchip MPP - i.e. /dev/mpp_service exists. Ubuntu or Debian userland both work. - This does NOT apply to the "current" or "edge" (mainline) kernel branches. Mainline has no MPP and uses a completely different path (V4L2 stateless). If /dev/mpp_service does not exist, you are on a mainline kernel and this guide does not apply. Check first: uname -r # expect something like 6.1.0-xxxx-rockchip (BSP), not mainline ls -l /dev/mpp_service # must exist. If "No such file or directory", you are on mainline. -------------------------------------------------- BACKGROUND - two different paths, for different browsers -------------------------------------------------- There are two separate hardware-decode paths on RK3588, and they cover different browsers. Know which one you want before you start: 1) The distro CHROMIUM path (rkmpp via the V4L2 shim). On Armbian you enable this through armbian-config, which installs the rockchip multimedia stack - rockchip-multimedia-config, libv4l-rkmpp, gstreamer1.0-rockchip - from ppa:liujianfeng1994/rockchip-multimedia (see armbian configng PR #887). That makes the distro Chromium hardware-decode. It does NOTHING for Google Chrome or Firefox, and it depends on that PPA having a build for your Ubuntu release (at the time of writing the PPA targets Noble; newer releases such as Resolute are not covered). 2) The VA-API path (THIS guide). Google Chrome and Firefox decode through VA-API (libva), not the Chromium/V4L2 shim. On a fresh BSP install VA-API is broken, because the Rockchip VA-API driver (rockchip_drv_video.so) is not installed - so Chrome and Firefox fall back to software. This guide installs that driver and points Chrome at it. Use path 1 (armbian-config) if you only want Chromium. Use this guide if you want hardware decode in Google Chrome or Firefox. The two can coexist on the same system. -------------------------------------------------- DOWNLOADS (with versions) -------------------------------------------------- 1) Google Chrome for arm64 (unlisted, but a genuine Google build): Download: https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb Version tested: 151.0.7922.137-1 Note: Google's download page only offers amd64. The arm64 file exists on the same server; you get it by swapping "amd64" for "arm64" in the URL. Installing the deb also adds Google's apt repo, so it self-updates. 2) Rockchip VA-API driver source: Source: https://github.com/woodyst/rockchip-vaapi Recommended fixes: https://github.com/woodyst/rockchip-vaapi/pull/2 (truongsinh PR #2 - fixes green bands, adds surface/RT-format reporting, H.264 B-frame handling, RGA blitter) Version: the built driver reports "Rockchip MPP VA-API Driver 0.1" -------------------------------------------------- STEP 1 - INSTALL THE ROCKCHIP VA-API DRIVER -------------------------------------------------- sudo apt update sudo apt install -y build-essential pkg-config git libva-dev librockchip-mpp-dev vainfo Note on librockchip-mpp-dev (the MPP build headers): on Armbian vendor it comes from ppa:liujianfeng1994/rockchip-multimedia. If you have already enabled Chromium hardware decode via armbian-config, that PPA is already added and the package installs directly. If it is not present for your release, install the runtime lib (librockchip-mpp1) and take the matching headers from the MPP source (https://github.com/rockchip-linux/mpp), then build against those. git clone https://github.com/woodyst/rockchip-vaapi.git cd rockchip-vaapi # Recommended: apply PR #2 correctness/perf fixes git fetch origin pull/2/head:pr2 && git checkout pr2 make DRIDIR=$(pkg-config --variable=driverdir libva) sudo install -m0644 rockchip_drv_video.so "$DRIDIR/rockchip_drv_video.so" # Tell all VA-API apps to use it (applies fully after next login) echo 'LIBVA_DRIVER_NAME=rockchip' | sudo tee -a /etc/environment Confirm it loads: vainfo You want to see "va_openDriver() returns 0" and a list of VAProfile entries, e.g.: vainfo: Driver version: Rockchip MPP VA-API Driver 0.1 VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD -------------------------------------------------- STEP 2 - INSTALL GOOGLE CHROME (arm64) -------------------------------------------------- cd ~ wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb sudo apt install -y ./google-chrome-stable_current_arm64.deb -------------------------------------------------- STEP 3 - PERSISTENT HARDWARE-DECODE LAUNCHER -------------------------------------------------- Chrome does not read a flags directory. Two things must be true every launch: (a) the hardware-decode flags are on, and (b) LIBVA_DRIVER_NAME=rockchip is in Chrome's environment (its sandbox blocks auto-detect). The reliable way is a small wrapper script plus a user-level launcher that survives Chrome's apt updates. Create the wrapper: mkdir -p ~/.local/bin cat > ~/.local/bin/google-chrome-hw <<'EOF' #!/bin/bash export LIBVA_DRIVER_NAME=rockchip exec /usr/bin/google-chrome-stable \ --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \ --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy --ozone-platform-hint=auto "$@" EOF chmod +x ~/.local/bin/google-chrome-hw Create a user-level launcher that points at the wrapper (overrides the system one): mkdir -p ~/.local/share/applications cp /usr/share/applications/google-chrome.desktop ~/.local/share/applications/ sed -i "s|/usr/bin/google-chrome-stable|$HOME/.local/bin/google-chrome-hw|g" \ ~/.local/share/applications/google-chrome.desktop -------------------------------------------------- STEP 4 - LOG OUT AND BACK IN (once) -------------------------------------------------- This makes two things take effect at once: the desktop re-reads your launcher (so the dock/menu icon uses the wrapper), and /etc/environment is applied to the whole session (so every app, including Chrome's child processes, gets LIBVA_DRIVER_NAME). -------------------------------------------------- STEP 5 - VERIFY IT IS ACTUALLY ON THE HARDWARE -------------------------------------------------- Launch Chrome from the dock/menu, play any video, then: - chrome://gpu -> "Video Decode: Hardware accelerated" (green). - Node-level proof - while a video plays: sudo fuser /dev/mpp_service If that prints a chrome PID, the VPU is doing the decode. During playback a chrome process should sit low (single-digit to low tens of percent of one core), not 150-400%. -------------------------------------------------- PROBLEMS AND FIXES -------------------------------------------------- 1) vainfo says: "va_openDriver() returns -1" / "vaInitialize failed" Cause: rockchip_drv_video.so is not installed. libva sees the DRM driver "rockchip-drm", looks for a matching VA driver named "rockchip", and finds nothing. Fix: do Step 1. Confirm the file exists: ls -l /usr/lib/aarch64-linux-gnu/dri/rockchip_drv_video.so 2) Chrome plays video but the CPU is very high and there is no hardware decode a) Flags not applied. You launched plain Chrome, not the wrapper. Chrome does not read a chromium.d flags dir. Use the wrapper/launcher from Step 3. Check chrome://gpu. b) Driver name not set. Chrome's sandbox blocks VA-API auto-detect, so LIBVA_DRIVER_NAME=rockchip must be in Chrome's environment. The wrapper exports it, and /etc/environment sets it session-wide after a re-login. (Unsandboxed vainfo works without it; Chrome does not - do not be fooled by vainfo passing.) 3) Putting "env VAR=val" in the .desktop Exec line does nothing The desktop launcher does not honor an "env" prefix in Exec. Use a wrapper script that exports the variable, as in Step 3. 4) The dock icon still launches Chrome without the flags after you made the override The desktop caches the app entry. Log out and back in (Step 4). To test immediately without logging out: gtk-launch google-chrome 5) You quit and relaunched Chrome but it still has the old (no) flags Chrome is single-instance per profile. Clicking the icon again just focuses the existing process. Fully quit first, confirm nothing is running, then launch: pkill chrome ; sleep 2 ; pgrep -x chrome # should print nothing (pkill chrome does NOT touch chromium - "chrome" is not inside "chromium".) 6) It looks like software even though everything is set up right Chrome throttles or pauses video in a background / occluded tab or window, which reads as "0% CPU, node idle". Test with the window focused or fullscreen. Also skip YouTube pre-roll ads (they are often a different codec). 7) AV1 content falls back to software This driver does not advertise AV1 by design (Rockchip MPP needs a full OBU bytestream, but VA-API hands it headerless tile data, so it cannot be wired up). H.264 / HEVC / VP8 / VP9 are hardware. For YouTube, set your account playback preference so it does not force AV1, and VP9 (which is hardware here) will be used. 😎 High CPU during 4K, especially at a 120 Hz refresh That is compositing/present cost, not decode. Confirm decode is still on the hardware: no single chrome process is pegged at 300-400%, and fuser /dev/mpp_service still shows chrome. Setting the display to 4K@60 roughly halves the compositing CPU (a 60 fps video does not need a 120 Hz present rate). 9) Do NOT add --disable-gpu-compositing It can cure some flicker, but it silently kills hardware video decode. Leave it off if you want HW video. 10) Note on the distro Chromium Chromium uses a different path (rkmpp via the V4L2 shim, not VA-API). On Armbian, enable that with armbian-config (the rockchip multimedia stack from ppa:liujianfeng1994/rockchip-multimedia, armbian configng PR #887) - not with this guide. This guide is for Google Chrome and Firefox, which the Chromium route does not cover. The two can coexist. -------------------------------------------------- FIREFOX BONUS (same driver) -------------------------------------------------- With the VA-API driver from Step 1 installed, Firefox also hardware-decodes: in about:config set media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true Verify in about:support (Media section) or with vainfo. -------------------------------------------------- TESTED ON -------------------------------------------------- - Orange Pi 5B (RK3588S), GNOME on Wayland, Rockchip 6.1 BSP userland - Developed and verified on a ubuntu-rockchip (Noble) BSP install; the procedure is the same on an Armbian vendor image - only the Step 1 build-package names can differ (see the note there) - Kernel: 6.1.0-1027-rockchip (ubuntu-rockchip); Armbian vendor is the equivalent Rockchip 6.1 BSP - google-chrome-stable: 151.0.7922.137-1 - librockchip-mpp / librockchip-mpp-dev: 1.5.0-1+git20240717.5275a9a6~noble - libva: 2.20.0 - Driver: Rockchip MPP VA-API Driver 0.1 (woodyst/rockchip-vaapi + PR #2) - Verified at 1080p and 4K (H.264 and VP9): /dev/mpp_service held by Chrome, CPU near idle, GPU load a few percent, temps in the high 50s to high 60s C. Firefox Install Adding since the scope of the guide includes Firefox. #!/usr/bin/env bash # rockchip-vaapi driver installer -- hardware video decode (VA-API) on RK3588/RK3588S # vendor (Rockchip 6.1 BSP) kernels. Installs the VA-API driver that Google Chrome AND # Firefox use, then points the system at it. Companion to the HOW-TO in this thread. # # Run: sudo bash rockchip-vaapi-install.sh # # Driver: github.com/woodyst/rockchip-vaapi + truongsinh PR #2 (green-band / RT-format / # H.264 B-frame / RGA fixes). Reports "Rockchip MPP VA-API Driver 0.1". set -euo pipefail [ "$(id -u)" = 0 ] || { echo "Please run with sudo: sudo bash $0" >&2; exit 1; } # This is the BSP/VA-API path. It needs /dev/mpp_service (vendor 6.1 kernel with Rockchip MPP). # Mainline (current/edge) kernels have no MPP and use a different path -- this won't apply. if [ ! -e /dev/mpp_service ]; then echo "ERROR: /dev/mpp_service not found -- you're on a mainline kernel (current/edge)." >&2 echo " This driver needs the VENDOR BSP kernel (uname -r shows ...-rockchip on 6.1)." >&2 exit 1 fi echo "==> Installing build + runtime dependencies..." export DEBIAN_FRONTEND=noninteractive apt-get update -y apt-get install -y --no-install-recommends \ build-essential pkg-config git libva-dev librockchip-mpp-dev vainfo echo "==> Building the Rockchip VA-API driver (woodyst + PR #2)..." tmp="$(mktemp -d)"; trap 'rm -rf "$tmp"' EXIT git clone https://github.com/woodyst/rockchip-vaapi.git "$tmp/src" cd "$tmp/src" git fetch origin pull/2/head:pr2 && git checkout pr2 # correctness/perf fixes make [ -f rockchip_drv_video.so ] || { echo "build failed -- no rockchip_drv_video.so produced." >&2; exit 1; } echo "==> Installing the driver..." DRIDIR="$(pkg-config --variable=driverdir libva 2>/dev/null || echo /usr/lib/aarch64-linux-gnu/dri)" install -d "$DRIDIR" install -m0644 rockchip_drv_video.so "$DRIDIR/rockchip_drv_video.so" echo " -> $DRIDIR/rockchip_drv_video.so" # Make all VA-API apps prefer this driver (applies fully after next login). if ! grep -q '^LIBVA_DRIVER_NAME=rockchip$' /etc/environment 2>/dev/null; then echo 'LIBVA_DRIVER_NAME=rockchip' >> /etc/environment echo " set LIBVA_DRIVER_NAME=rockchip in /etc/environment" fi echo "==> Verifying with vainfo..." if LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | grep -q 'va_openDriver() returns 0'; then LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | grep -E 'Driver version|VAProfile' | sed 's/^/ /' echo "==> Driver loads and reports HW decode profiles. OK" else echo "!! vainfo did not confirm the driver. Full output:" LIBVA_DRIVER_NAME=rockchip vainfo 2>&1 | sed 's/^/ /' || true fi cat <<'EOF' ============================================================ Driver installed. Log OUT and back in once (so LIBVA_DRIVER_NAME applies session-wide), then enable HW decode in your browser per the HOW-TO above: - Google Chrome : the wrapper + .desktop override (Steps 2-3) - Firefox : about:config -> media.ffmpeg.vaapi.enabled = true media.hardware-video-decoding.enabled = true Hardware codecs: H.264 / HEVC / VP8 / VP9 (no AV1 -- by design) Verify: chrome://gpu (Video Decode: Hardware accelerated), or during playback `sudo fuser /dev/mpp_service` should show your browser's PID. ============================================================ EOF -------------------------------------------------- CREDITS -------------------------------------------------- - VA-API driver: woodyst/rockchip-vaapi - Fixes: truongsinh, PR #2 - BSP image / MPP userland: Joshua Riek (ubuntu-rockchip) https://interfacinglinux.com/community/sbcsoftware/installing-official-chrome-for-arm64-linux-desktop/#post-1246 "Got Two Claudes & A Turntable"

I'm older and not much time allowed to "F" off. I used to spend time in my late 30's On Q3A InstaUnlagged. I'm using AI The best I can to do the things I dont have time for. I bought a OP5b before our house flooded and then I started AI for geneology.. went f'n amazing... Family came here from France in 1624. In 1924 there was a commemorative coin and 2 stamps celebrating my family and other French and Belgium Huguenots working the American Dream, with religious freedoms... Then a book about our Family's farm in Central Park. An artist hired to painting of the description of the farm.. So I bought the coin, the two stamps, the painting, the book and the French Bible that was protested.. Calvin.. Then I had bought the max Claude. Which after a few bs ideas I dragged the Orange PI 5b out and I said hey Joshua Riek is done I would like an OS with security updates and this new PR for 4k120hz and You know I could never get Widevine working right., lets do that. This Plex Server sucks for my hires Needle drops it's always lagging. Build me a app to play it right.. Oh f my bluetooth is shit I have to reboot to get it back.. Fixed So here we are contributing to Armbian And Sonic Pi. Hello, defcom5-rockchip real conversation with Claude. : Pi Studio is genuinely done. Every check green, including the two that failed the last two bakes: /opt/sonic-pi/VERSION: 5.0.0 ← Final, not beta4 flute reg: 1 harmonica reg: 1 ← both registered synthdefs: 2 (flute+harmonica) no sonic-pi DEB installed ← hook-only, beta4 deb retired cleanly Full image state — pistudio-orangepi-5b-NOFLICKER-allapps.img.xz (4.8G, 18:09): Component Status Kernel 1027 CVE (SMP PREEMPT + SCO fix + AFBC-reject) (Pi Claude also confirmed VP9 4K HW-decode + 4K@120 flicker-free) Sonic Pi 5.0.0 Final — flute + harmonica play oem-config intact (first boot creates the user, no hand-patch) snapd gone · first-boot-hygiene · Chromium 132 rkmpp · Pro Updates · surge-xt This one flashes clean with no card surgery — oem-config runs, makes the account, boots to a Pi Studio desktop where :flute and :harmonica actually sound. That's the whole "let's get Pi Studio done" arc closed. Three build bugs fixed and logged along the way so they can't recur: the FLAVOR-gate dash trap, the oem-config first-boot mask, and the sonic-pi dual-delivery (deb glob clobbering the hook). I owe Pi Claude a reply-back on the share confirming: Sonic Pi 5.0.0 Final is baked (flute+harmonica verified), the beta4 deb is retired, and — important — the mask oem-config.service recommendation must NOT be applied (it strands first boot; that's why we hit it). Want me to write that HANDOFF-BACK-to-PC-Claude-style reply now, or eyeball it first? See less The I owe is funny to me.

Yup and fixed.

Cross-posting this because it took a while to untangle, and most guides out there are either vendor-BSP/rkmpp (the wrong stack for mainline) or they stop at "it says hardware accelerated" without checking whether it actually is. Tested on an Orange Pi 5B, mainline Debian 13 (trixie), kernel 7.1.3+deb13-arm64, panthor + PanVK, Wayfire. Should apply to any RK3588/RK3588S board on a mainline stateless-decode kernel (Rock 5B, OPi 5, etc.). Corrections welcome; I'd rather this be right than mine. First, the thing that trips everyone up: on mainline, rkmpp is not your path. Rockchip's MPP library (the thing that hardware-decodes at ~9% CPU on the vendor BSP images) talks to /dev/mpp_service. That device only exists on the vendor kernel. On mainline/panthor there is no mpp_service and there never will be, so every rkmpp-based ffmpeg/Chromium build is a dead end here. And no, the GPU doesn't help. PanVK exposes zero VK_KHR_video_decode extensions. Mali-G610 has no video engine. Vulkan composites and scales the decoded frames; it never produces them. The decode blocks are separate silicon (rkvdec, Hantro) behind a separate kernel API. The mainline path is V4L2 stateless (the request API), the work Collabora and Jernej Skrabec carry upstream, with the userspace ffmpeg side maintained by Kwiboo (Jonas Karlman). The kernel drivers are already there; on my box the v4l2_h264/v4l2_vp9 helpers are loaded and bound to rkvdec/hantro_vpu out of the box. What's missing is a userspace that speaks the request API. Stock Debian ffmpeg doesn't, so it silently decodes in software (1080p H.264 is about 600% CPU, six cores pegged). Check what your kernel actually exposes before anything else: for v in /dev/video*; do echo "== $v =="; v4l2-ctl -d $v --list-formats-out 2>/dev/null | grep -oE "'[A-Z0-9]{4}'"; done On my 7.1.3 kernel: /dev/video1 (rkvdec) -> S264 S265 (H.264, HEVC) /dev/video2 (rk3568-vpu) -> S264 VP8F MG2S (H.264, VP8, MPEG-2) /dev/video4 (rk3588-av1-vpu-dec) -> AV1F (AV1, advertises up to 4096x2304) VP9 is NOT exposed on this kernel; that is a beryllium/7.2-rc5+ restore (VP9-on-VDPU381). More on why that barely matters below. Part A: system-wide HW decode (mpv, VLC, GStreamer, everything) Build Kwiboo's FFmpeg fork, branch v4l2-request-n7.1.3. The version choice is deliberate: ffmpeg 7.1.3 is libavcodec.so.61, the same soname as Debian trixie's 7.1.5, so it is a genuine drop-in. You swap one component and every libav app hardware-decodes with zero rebuilds. (The newer n8.x branches are .so.62 and become an island: only the one binary you point at them benefits.) sudo apt install build-essential git nasm pkg-config libdrm-dev libudev-dev v4l-utils \ libx264-dev libx265-dev libvpx-dev libopus-dev libvorbis-dev libmp3lame-dev libdav1d-dev libva-dev git clone -b v4l2-request-n7.1.3 https://github.com/Kwiboo/FFmpeg ffmpeg-7131 && cd ffmpeg-7131 ./configure --prefix=/usr/local --enable-shared --disable-static \ --enable-gpl --enable-version3 --enable-v4l2-request --enable-libdrm \ --enable-libx264 --enable-libx265 --enable-libvpx --enable-libopus \ --enable-libvorbis --enable-libmp3lame --enable-libdav1d --disable-vulkan --disable-doc make -j$(nproc) Build gotcha that cost me an hour: do NOT add --enable-libv4l2. On n7.1.3 its libavdevice/v4l2.c fails to compile against current libv4l headers (the SET_WRAPPERS macro). That is the webcam-capture indev, nothing to do with request-API decode. Leave it off. Test before installing anything system-wide, with stock mpv pointed at the fresh libs: LD_LIBRARY_PATH=/usr/local/lib mpv --hwdec=v4l2request-copy --gpu-api=vulkan yourfile.mp4 You want to see "Using hardware decoding (v4l2request-copy)" and pixfmt drm_prime. My numbers: 1080p H.264 went from about 600% CPU (software) to about 37% of one core. Then package it as a .deb that Provides/Conflicts/Replaces the eight Debian libav* packages (= 7:7.1.5-0+deb13u1) and installs your .so.61 plus symlinks into /usr/lib/aarch64-linux-gnu/. apt treats it as satisfying the deps, so mpv/vlc/gstreamer/qt-multimedia all stay installed and all start hardware-decoding. Cache the stock debs first (apt download the eight) so rollback is one command. Honest tradeoff: this replaces your system libav with a fork, so (a) the blast radius is every media app, and (b) you now own libav security. When Debian bumps 7.1.x for a CVE, you rebuild the one deb. I think that is a fair price for one-component maintenance versus forking every app. Your call. Part B: in-browser HW decode (Chromium), and a myth to kill You do not need a forked Chromium, and you do not need the libva-v4l2-request VA-API shim for the browser. Both are things the vendor/rkmpp world needs; mainline does not. Two facts do the work: 1. Debian trixie already ships Chromium 151, past the upstream 150 ANGLE roll that fixed the old VP9 green-artifact bug. Stock: apt install chromium. 2. Chromium bundles its own ffmpeg, and its AcceleratedVideoDecoder talks V4L2-stateless straight to /dev/videoN. So Part A's libav swap is irrelevant to the browser; the two paths are independent. Debian's chromium launcher sources /etc/chromium.d/*, so drop a flag file: # /etc/chromium.d/50-hwdecode export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ozone-platform-hint=auto \ --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \ --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy" Notes: - The flag that actually gates it is AcceleratedVideoDecoder. The older AcceleratedVideoDecodeLinuxV4L2 no longer exists in 150+ and is silently ignored. - It needs a Wayland session. --ozone-platform-hint=auto picks it under Wayfire/wlroots. Result: browser H.264 held /dev/video1 at about 23% of one core. AV1 held /dev/video4. Which brings us to the part that actually stumped me. Part 😄 the 4K@30 gotcha. cma=256M is too small, and it fails silently. This is the reason I wrote the post. In-browser AV1 worked perfectly at 1080p: decoder node held, about 26% of one core, 95% idle. Force the same av01 stream to 2160p and it dropped straight back to software: one Chromium process at about 400%, /dev/video4 idle, and stats-for-nerds still reading av01. Same codec, two outcomes. The tell that it is not the codec: the AV1 block advertises up to 4096x2304, so 4K is in spec. It is not a capability ceiling. The kernel log named it exactly: cma: __cma_alloc_frozen: alloc failed, req-size: 3421 pages, ret: -16 hantro_postproc_alloc -> dma_alloc_attrs -> hantro_start_streaming The Hantro decoder needs a roughly 13 MB contiguous buffer for a 4K frame, and the default cma=256M pool was too fragmented to hand it out. hantro_start_streaming bails, and Chromium does what it is designed to do: falls back to software, silently, with no error on screen. At 1080p the buffer is a quarter the size and fits; at 4K it does not. Fix (a boot argument, not a kernel rebuild): bump the CMA reservation. On the mainline extlinux setup that is: # /boot/extlinux/extlinux.conf -> in the "append ..." line(s), and # /etc/default/u-boot -> U_BOOT_PARAMETERS (the template extlinux regenerates from) cma=256M becomes cma=1G Edit both, or a future u-boot-update reverts you. Reboot. (The other fix you will see mentioned is CONFIG_VSI_IOMMU=y, which lets the AV1 VPU scatter-gather through the IOMMU and sidestep the contiguous requirement, but that is a kernel rebuild. The boot arg is free.) After cma=1G (CmaTotal 1 GB): the same 4K av01 fullscreen stream went from four pegged cores to 58% of one core, 91% idle, decoder node held, zero allocation failures, and it ran cooler (47C to 36C). 256 MB is simply too small a house for 4K decode on this SoC. Ship 512M or more; I use 1G. Codec support, honestly (this kernel): H.264 yes, HEVC yes, AV1 yes (including 4K with the CMA bump), VP8/MPEG-2 yes, VP9 is software (not in 7.1.3; needs beryllium/7.2+). In practice the VP9 gap barely bites: because Chromium now advertises AV1 decode, YouTube negotiates av01 at every resolution I tested (1080p and 4K), and only reaches for VP9 in ads. So I am leaving VP9 to upstream rather than chasing a custom kernel. How to actually verify HW decode (do not trust chrome://gpu): it reports a capability ("Video Decode: Hardware accelerated") that stays true even while a given stream decodes in software. The only honest test is who holds the decode node, sampled during steady playback (not during an ad or a quality ramp; those transients will lie to a CPU snapshot): fuser /dev/video1 /dev/video2 /dev/video4 # whoever holds it is the real decoder Cross-check in the browser at chrome://media-internals: kVideoDecoderName is V4L2VideoDecoder, and kIsPlatformVideoDecoder is true. The build this ran on (for reproducibility) Nothing exotic; the point is it is stock trixie + backports, not a vendor BSP. This is a mainline Debian desktop I put together for the 5B (my own image line, "Pi Phreak"): - Board: Xunlong Orange Pi 5B, RK3588S (4x Cortex-A76 + 4x Cortex-A55), Mali-G610 MC4, 16 GB - OS: Debian 13 (trixie), with trixie-backports enabled - Kernel: 7.1.3+deb13-arm64, mainline (stateless V4L2 decoders, panthor), booted with cma=1G - GPU stack: Mesa 26.1.2 (~bpo13), Vulkan 1.4 via PanVK on Mali-G610 (loader 1.4.309), GLES 3.1 - Compositor: Wayfire 0.11.0 on wlroots 0.20.2 (built from source; trixie ships 0.9), plus swaybg / waybar / wofi / foot - Media: Chromium 151 (stock Debian) + the /etc/chromium.d flags, mpv 0.40, system libav = the Kwiboo v4l2-request 7.1.3 drop-in (7:7.1.3-phreak1, soname-matched to 7.1.5) Two things to flag for anyone reproducing this: Mesa/PanVK come from trixie-backports (stock trixie Mesa is older and PanVK is not 1.4 there, a separate "package version is not hardware capability" trap), and the 16 GB headroom is what makes a 1 GB CMA reservation painless. On an 8 GB board I would still bump past 256M (try 512M) but keep an eye on free RAM. Credits: Kwiboo (Jonas Karlman) for the FFmpeg v4l2-request fork; Collabora / Jernej Skrabec for the mainline stateless decoders; the dongioia/rock5bplus-rkvdec2 writeup for the Chromium-150 flag findings; beryllium-org for the packaging reference and the VP9/VDPU381 kernel note. I only assembled and measured; the hard part is theirs. Happy to answer questions or hand over the packaging scripts if it is useful. Peace, Defcom5-Rockchip "Got 2 Claudes and A Turntable" Sorry I got my Flagship baking and excited working on my new Debian build with the above outlined and the honey its f in due list! 2 things I've learned about AI. 1. Don't Trust Them, you have to tell them like they are children. (They act like they know). 2. Don't Trust Them.

Orange Pi 5B subforum has recurring threads about eMMC boot loops, WiFi/Bluetooth regressions on mainline kernels, and the general "what image actually works on this thing" question. Joshua-Riek's ubuntu-rockchip was a common answer to that for a long time, but it was archived recently. This is a personal continuation fork in case it's useful to anyone working through those same issues. What this is: - Fork of Joshua-Riek/ubuntu-rockchip (archived) — same vendor 6.1 kernel base, not mainline - Therefore: onboard WiFi/BT works (no mainline driver regressions), eMMC boots reliably - Scope: Orange Pi 5B + Ubuntu 24.04 (Noble) only. jammy/oracular/plucky suite configs removed. - Single-maintainer hobby project. Best-effort, no SLA. v1.0.0 contents: - Kernel ABI bumped to 6.1.0-1027.27 - Backported CVE-2026-46333 (ssh-keysign-pwn) — upstream commit 31e62c2ebbfd cherry-picked onto noble-security branch - Build-kernel.sh patched for GCC 14+ host compatibility (the 6.1 vendor tree's -Werror defaults conflict with stricter warning-to-error promotion introduced in GCC 14 and inherited by GCC 15)"— the 6.1 vendor tree fails to compile on Ubuntu 24.04+ / Debian Trixie+ hosts due to -Werror promotion. Fix is KCFLAGS=-Wno-error for the kernel proper plus sed-stripping hardcoded -Werror from libbpf, libsubcmd, objtool, and libperf tool Makefiles. Without this, you can't rebuild Joshua's kernel from source on a modern host. - Tested as a daily driver on OPi 5B hardware with reboot loop test, cpu burn. running 4k screensaver. Known limitations (carried over from upstream): - Mali GPU PPA (panfork-mesa) and jjriek/rockchip userspace PPAs are no longer maintained. Frozen at the versions Joshua left them. Not a competitor to Armbian — different scope, different kernel approach. If you're getting clean results with Armbian on your 5B, stick with what works. This is for the case where Armbian's mainline kernel breaks onboard hardware or you specifically need the Joshua-Riek tree. Credit: this is a continuation, not original work. Joshua-Riek did the heavy lifting; LICENSE, NOTICE, and README all credit upstream. Repo: https://github.com/defcom5-rockchip/ubuntu-rockchip Kernel: https://github.com/defcom5-rockchip/linux-rockchip-rk3588 Release: https://github.com/defcom5-rockchip/ubuntu-rockchip/releases/tag/defcom5-v1.0.0 (1.86GB .img.xz + sha256) Peace, defcom5

Yeah no problem, heading to GitHub. No forum for Ubuntu and you are not covering the 5b so I tried. They will care about solid performance. defcom5

Working with Claude.AI I have Joshua's kernel updated and cherry picked to have latest security fix. I have it on my Orange Pi 5b, on the Emmc. running 24/7, burn test, 4k video for screen saver. widevine in Vivaldi and chromium/Visual Studio Flicker fix. I am waiting on new Antennas to arrive for Bluetooth check. Currently hosted on Private Github, working towards public consumption. I'll let the AI tell the story. defcom5