I think there is an option somewhere in armbian-config to edit the device tree. How to diff: https://www.perplexity.ai/search/create-a-short-and-shareable-e-8cKctYlWQJO8jKY0vDOKgg

 

45 minutes ago, JFL said:

https://github.com/armbian/build/pull/9600

I don't think so but you can try reverting this pr and do a test build.

Quote

 

  4 hours ago, JFL said:

https://github.com/armbian/build/pull/9600

I don't think so but you can try reverting this pr and do a test build.

 

I do not meant that the above causes the NO Analog Output issue.  I don't think those patches were in the earlier kernekl 6.18.20-current=rockchip64-26.2.0-trunk.640 or the kernel-7.0.0-rc5-edge-rockchip64-26.2.0-trunk.626.  These patches are added totay or yesterday.

 

On the contrary, could the https://github.com/armbian/build/pull/9600 resolved the NO Analog Output issue on Opi5-Plus.

Just an update.  Upgraded to linux-image-current-rockchip64-26.2.0-trunk.655 (6.18.20) not sure whether it included this

 

Quote

OrangePi5Pro: Comprehensive HW Support: YT6801 PCIe-Eth, Codec ES8388 Audio, eFUSE & U-Boot v2025.10#9600

Audio (ES8388) LRCK Sharing: The board's hardware design requires the capture and playback interfaces to share the same clock line. I patched the es8328 ASoC driver to explicitly allow LRCK sharing and added missing Mic Bias routing to the DTS. Both onboard mic and headphone jack now work flawlessly.

 

But unfortunately with the new linux-image-current-rockchip64-26.2.0-trunk.655 kernel still no audio/sound output from the Headphone Jack (Analog)..

Edit: Downgraded to or Install linux-image-current-rockchip64-26.2.1 (6.18.10), Headphone Jack has audio/sound output.

Edited March 30Mar 30 by JFL

Quote

 

Hi, could you try the following addition in the device tree?

 

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi index 3bceee948458..e58d7e69e8e8 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi @@ -273,9 +273,9 @@ es8388: audio-codec@11 { reg = <0x11>; /* On RK3588 (not RK3588S), MCLK output is gated and must use TO_IO variant */ clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>; - assigned-clocks = <&cru I2S0_8CH_MCLKOUT>; + assigned-clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>; assigned-clock-rates = <12288000>; AVDD-supply = <&vcc_3v3_s0>; DVDD-supply = <&vcc_1v8_s0>;

 

Hi @Werner

For your info, with kernel-6.19.5-edge-rockchip64 using dtb from kernel-7.0.0-rc5/rc6-edge-rockchip64, Headphone Jack audio/sound is available.  Does this mean the device tree is not the culprit and it is related to the kernel?

Have not tried not tried booting up kernel-6.18.10-current-rockchip64 with device tree from kernel-6.18.20-current-rockchip64.

 

 

I don't know. I don't maintain this board. Perhaps the maintainer knows which is alexl83. I don't know if he has a forums account though. Try via Github

Hi,

 

Quote

I don't know. I don't maintain this board. Perhaps the maintainer knows which is alexl83. I don't know if he has a forums account though. Try via Github

Is it appropriate to raise this at 

https://github.com/armbian/build/issues, since the Headphone Jack audio is available on older version of the kernels and not available in the latest kernels?

 

Thanks for your guidance.

On 3/28/2026 at 6:01 PM, Werner said:

/* On RK3588 (not RK3588S), MCLK output is gated and must use TO_IO variant */

 

Does this come from the patch I recently submitted to the maillist? I think it should work there too; the issue is present on all boards with the RK3588 chip.

46 minutes ago, SuperKali said:

Does this come from the patch I recently submitted to the maillist?

No, I let LLM poking at the problem.

19 minutes ago, Werner said:

No, I let LLM poking at the problem.

LLM has most likely read the patch I merged into Armbian

Hi, Just an update on this issue. 

Upgraded to kernel-7.0.0-edge-rockchip64-26.2.0-trunk.733, still no audio output on Analog Headphone/Audio Jack.
 

Just an update.  Both kernel-7.0.11-edge-rockchip64-26.8.0-trunk.94 and 6.18.34-current-rockchip64-26.8.0-trunk.94 both still NO analog audio output on Headphone Jack on Orange Pi 5-Plus

 

Kernel-6.18.10-current-rockchip64-6.2.1 and 6.19.5-edge-rockchip64 both support analog audio output on Headphone Jack.

 

By the way kernel-6.1.115-vendor-rk35xx also NO analog audio output.  kernel-6.1.75-vendor-rk35xx support analog audio output.

Edited June 5Jun 5 by JFL

After a lot of attemps with kernel versions and so on without any result this is the simple solution: Buy an USB to analog adaptor for 6 euro's brand MOSWAG, that's all folks.

Hey! i had similar issues with the ES8388 analog and HDMI output path alignment on my OPi5 Plus under recent edge/mainline kernels. Sometimes the card states look fine in ALSA/pavucontrol but the streams just don't bridge to the hardware mapping properly, or the default audio levels are hitting gain issues.

To test if it’s just a software-side compression or file amplification issue before diving too deep into modifying the device tree (.dts), try running a quick format check with a known sample using explicit routing- aplay -D plughw:1,0 your_audio.wav

If your test files are inherently too quiet or failing to hit the threshold cleanly, you can boost them up beforehand via tools like MP3Louder just to make sure you aren't fighting low baseline source levels on top of the kernel driver bugs. If it completely stays dead silent even with clean, forced audio files, then it's definitely the device tree overlay parameters (simple-audio-card) not toggling correctly on your specific build version. Which image build date and kernel version are you currently on?

Got analog jack working again on vendor 6.1.115.

 

After 6.1.75 Rockchip added mute switches that boot off, so jack detect still works and HDMI is fine, but the 3.5 mm stays silent.

 

The commit is https://github.com/armbian/linux-rockchip/commit/4389dbd8ec41 

Issue: https://github.com/armbian/linux-rockchip/issues/364 

This is only vendor 6.1. The 6.18 / 7.0 jack breakage is a different stack.

 

 

On a running 6.1.84+ (up to 6.1.115) vendor image:

 

amixer -c rockchipes8388 sset OUT1 on
amixer -c rockchipes8388 sset Headphone on
amixer -c rockchipes8388 sset 'hp switch' on
speaker-test -D plughw:rockchipes8388 -c 2 -t wav

 

If there's no `rockchipes8388`, check `cat /proc/asound/cards` and use that card number.

 

To keep it after reboot:

 

sudo alsactl store
sudo systemctl enable --now alsa-restore.service

 

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.

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

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>

Edited August 20Aug 20 by defcom5-rockchip

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. 

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.

 

Just now, defcom5-rockchip said:

OK this is for OP5b:  Different fix

Confirmed the key thing — and it's a register misread worth catching before Pi Claude chases the wrong one. Here's the source-dig result:

What the driver actually does (unambiguous in the code)

bclk_rate = frame_width * rate; // 64 * 48000 = 3.072 MHz div_bclk = DIV_ROUND_CLOSEST(mclk_rate, bclk_rate); // MCLK→BCLK divider → should be 4 div_lrck = bclk_rate / rate; // = frame_width → should be 64 ... I2S_CLKDIV_TXM(div_bclk) // div_bclk goes into I2S_CLKDIV I2S_CKR_TSD(div_lrck) // div_lrck goes into I2S_CKR ← the register Pi Claude dumped

So I2S_CKR TSD/RSD = div_lrck = frame_width = the BCLK→LRCK (frame) divider — and 0x3f (÷64) is CORRECT for 64fs. Pi Claude read that 0x3f as "the bclk divider, should be ÷4" — but it's not the bclk divider at all. The MCLK→BCLK divider lives in I2S_CLKDIV (TXM/RXM), which was not in his regmap dump.

But his instinct that something is 16× is right — here's where it actually is

The math nails the location:

LRCK = MCLK / (div_bclk × div_lrck) 3 kHz observed, div_lrck = 64 (from CKR) ⟹ div_bclk = 64 (should be 4 → 16× too big)

So the real fault is div_bclk = 64 in I2S_CLKDIV (undumped), not CKR. And since div_bclk = DIV_ROUND_CLOSEST(mclk_rate, 64×48000), getting 64 instead of 4 means the mclk_rate the driver saw at compute-time was ~196.6 MHz (= 12.288 × 16), not the 12.288 MHz measured at the codec pin. That's the actual bug hypothesis: the mclk the driver rate-queries and the mclk reaching the codec are inconsistent by 16×.

 

Hi,Just an update.  With kernel-7.1.8-edge-rockchip64, Analog audio output is available from the Analog/Headphone Jack on Opi5-Plus.

 

Quote

 

linux-image-edge-rockchip64/now 26.11.0-trunk.10 arm64 [installed,local]

Linux orangepi5-plus 7.1.8-edge-rockchip64 #1 SMP PREEMPT Sun Aug  9 18:26:58 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux

 

 

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.

On 8/16/2026 at 4:57 AM, vlw said:

On a running 6.1.84+ (up to 6.1.115) vendor image:

 

amixer -c rockchipes8388 sset OUT1 on
amixer -c rockchipes8388 sset Headphone on
amixer -c rockchipes8388 sset 'hp switch' on
speaker-test -D plughw:rockchipes8388 -c 2 -t wav

 

Hi @vlw

 

Thanks for the tips.  The above commands resolved the NO Analog Audio output for Armbian-opi5plus-KDE-Neon-6.1.172-vendor-rk35xx-26.11.0-trunk.37.