The Tall Man

I recently had to modify a device tree file for a different reason. I showed what I did (and how I did it) here: https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/?do=findComment&comment=224923 To summarize, I used the device-tree-compiler package (command line: dtc) to convert the device tree binary (.dtb) file to a device tree source (.dts) file. Then I edited the .dts file, then converted it back. The process won't show you all the variable names, but the resulting .dts is readable enough to likely see what and where you need to change... and even moreso if you have the original (pre-compiled) .dts file to compare it with. If you need to match variable names with specific numbers, they will likely be #defined in the #includes at the top of the original .dts file.

This will cause update-grub to add the following a devicetree line to all menu entries. This example is based on Debian Trixie's grub-efi. This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels: -rw-r--r-- 1 root root 336036 Aug 27 04:10 config-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 343394 Sep 6 12:48 config-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ lrwxrwxrwx 1 root root 43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/ lrwxrwxrwx 1 root root 42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ drwxr-xr-x 3 root root 4096 Sep 20 15:13 efi drwxr-xr-x 5 root root 4096 Sep 20 16:26 grub lrwxrwxrwx 1 root root 29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64 -rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64 -rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 83 Aug 27 04:10 System.map-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 92 Sep 6 12:48 System.map-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64 -rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 41507328 Sep 6 12:48 vmlinuz-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64 Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does. For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/10_linux 2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189) linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args} 3. Just above it, add your own system's version of this line: devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus: devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/30_os-prober 2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297) linux ${LKERNEL} ${LPARAMS} 3. Just above it, add your own system's version of this line: devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg

I have an OrangePI 5 Plus, which is based on the rk3588 (arm64) SoC. I've installed Debian Trixie directly from their .iso installer (using an EFI booter) and it works - although I had to upgrade the kernel to the latest backported version to get GPU and audio. But the Armbian edge kernel (Rockchip64 in my case) works even better when install that package onto the pure Debian. I looked up that Chromebook and see it's based on the rk3288C, which is apparently a 32-bit arm (armhf)? If that's the case, you can download the Debian .iso installer here: https://cdimage.debian.org/debian-cd/current/armhf/iso-dvd/ Then if Armbian has an edge kernel for the rk3288, try it out to improve upon what Debian provides. I did find this page on Debian's site, but it doesn't look like it would be much help.: https://wiki.debian.org/InstallingDebianOn/Asus/C100P There is a Debian page for a similar computer that may be more helpful if you can adapt it to yours? https://wiki.debian.org/InstallingDebianOn/Asus/C101PA Note that the above two links were probably created long before Trixie. P.S. Even better is a full linux tutorial for your specific computer. In a search engine, I looked up: installing linux on ASUS ChromeBook C100P ...and this was a result: https://archlinuxarm.org/platforms/armv7/rockchip/asus-chromebook-flip-c100p

Same. But once you're in, you can run armbian-config and switch to the edge kernel. It'll work better. Just don't switch to the "current" kernel. 6.1 = Vendor Kernel 6.12 = Current Kernel 6.16 = Edge Kernel

Summary Update: A Look At Pure Ubuntu (no Armbian) --> The bug was there, then it was not! Initial Observation: Debian 13 (Trixie) The Bug Is Present Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.16.4-edge-rockchip64 (64-bit) Graphics Platform: Wayland Ubuntu 25.04 The Bug Is Present Distributor ID: Ubuntu Description: Ubuntu 25.04 Release: 25.04 Codename: plucky Operating System: Ubuntu 12 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Ubuntu 25.10 The Bug Is Gone! Distributor ID: Ubuntu Description: Ubuntu Questing Quokka (development branch) Release: 25.10 Codename: questing Operating System: Ubuntu 13 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Conclusion The bug was in Ubuntu. Then it wasn't. So the answers to how to fix it are likely in the changes made in or by Ubuntu.

Update: I just ran Ubuntu 13 (25.10 (development branch)), downloaded from their site (not Armbian), running their kernel. There I installed KDE Plasma 6.. Wayland performance was excellent. The bug I described here didn't show up at all. This version of Ubuntu seems more similar to Trixie than Bookworm. And some of their related package names, like Trixie's, did seem to mention porting from QT5 to QT6. So whatever bug is existing in Trixie was either not created, skipped, or solved by Ubuntu. Operating System: Ubuntu 13 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-13-generic (64-bit) Graphics Platform: Wayland

The board I have has a different Rockchip SoC (rk3588-orangepi-5-plus), but it's been my experience that the edge kernel (6.16) is the only one that's of any real use to me. I get no video with the "current" (6.12) kernel, and no GPU acceleration with the vendor (6.1) kernel. So I would suggest just switching to the edge kernel.

On the OrangePI-5-Plus, using an edge kernel, I've found that the desktop environment's GPU rendering works very smoothly on Wayland, in KDE 6 on Debian Trixie. It renders much more smoothly than gnome with Wayland (it's been my experience that the edge kernel is the only one that works). But I've encountered a major rendering bug. It only appears in Trixie KDE Plasma 6 with Wayland rendering. It does not appear when using x11 or when using either rendering in gnome. Nor does it appear at all in Bookworm. I have tried all kinds of things to "fix" these to no avail, including installing more wayland and mesa packages, then upgrading them to stable backports and then even to unstable testing (forky) versions. I've also tried the Debian unstable edge kernel from testing (6.16.3) as well as the Armbian stable edge kernel (6.16.4) with the same results. I installed Debian Trixie using the Debian .iso installer (w/ EFI boot), then upgraded to their edge/testing kernel (6.16.3) from their testing/forky repository. The bug showed up in pure Debian without a drop of Armbian. Then I installed the Armbian stable edge kernel (6.16.4) to replace the Debian edge/testing kernel in that installation. The bug remained. The rendering bug also showed up in the release version of Armbian Trixie 25.8.1 using the Armbian edge kernel. KDE 6 Wayland Render Bug Symptom: The [ALT-TAB] Task-Switcher's Text Labels (see screenshot #1) The major place this bug shows up is in the task switcher (using ALT-TAB). The window labels, instead of rendering as textual fonts, they render as blocks. I tried several things with the fonts, from changing their type and size, turning on/off anti-aliasing, to changing the desktop themes, and so on. I also tried using different "task switchers" from the list. All I got were the same blocks -they just appeared in different sizes and positions with no other changes. So I'm reasonably sure the rendering issue has nothing to do with fonts, desktop themes, Plasma settings, etc. KDE 6 Wayland Render Bug Symptom: glmark2 (x11) verses glmark2-wayland (see screenshots #2 and #3) Using the command-line utility: glmark2, there's an x11 version and a Wayland version. The each render to an 800x600 window. Normally the only visual difference between them is that the Wayland version has no window borders around it. But with this bug, the Wayland version renders significantly smaller on the screen, and also at a significant performance reduction (>50%). Conclusion I already know it isn't an Armbian issue. I don't believe it's a kernel issue either. I'm reasonably sure it has nothing to do with fonts, themes, or Plasma settings. In my internet searches, I have found no other reports of this specific rendering bug that I think are relevant to whatever is happening now. I did find some vague statements about there still being some "issues" with rendering in the upgrade from KDE 5 (using QT5 libraries) to KDE 6 (using QT6 libraries). I also read that KDE Plasma 6 has a somewhat unique interface or relationship with Wayland and uses its own protocols with it. I think this explains why the bug doesn't show up in gnome, and also helps to isolate, to a degree, where the bug actually is. From what I've read, apparently this issue shows up differently on different systems? It is my impression that these specific symptoms of this bug may be unique to this hardware (Rockchip rk3588 SoC) or GPU (MALI-G610 (built-in)), even though it is a clearly a software bug. Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.16.4-edge-rockchip64 (64-bit) Graphics Platform: Wayland EDIT: P.S. I just ran Fedora's KDE Plasma 6 image. There were about a thousand updates to run on it. Plasma 6.3.4 (think) upgraded to version 6.4. And their mainline kernel (6.14 upgraded to 6.16.7 I think). The rendering bug I mentioned here did not show up either before or after those updates. So it appears the issue isn't with KDE Plasma itself either, that it's apparently on Debian's end. I noticed some of the (Debian) packages are specifically to bridge 5 and 6. I would guess that's where the problem is - apparently they didn't make a clean break. Screenshot #1: [ALT-TAB] task-switcher Screenshot #2: glmark2 Screenshot #3: glmark2-wayland

Terrific! You're welcome!

That module is not included in the default kernel build configuration. But you can build the kernel yourself. https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://docs.armbian.com/Developer-Guide_Build-Commands/ When you run ./compile.sh, the first thing it shows you is the kernel configuration screen (image 1). Select, "Show a kernel configuration menu before compilation". When it finally arrives on the configuration menu (image 2), use the forward slash key (/) for search, enter ntsync. When the result comes up (image 3), press 1 to select it. It will take you right to it. It will be highlighted (image 4). Press the M key to select it as a module. The use the right arrow to move from Select to Exit, and keep doing that until you get to where you save it. Then keep going with the rest of the process. I could be wrong about this, but I think you can build the kernel only without the whole armbian image too, with this (from the second link above); ./compile.sh kernel-config BOARD=orangepi5 BRANCH=edge Image 1: Select Kernel Configuration Image 2: Kernel Configuration Menu Image 3: Search Result - NTSYNC Image 4: - NTSYNC Selection

One issue with Debian Trixie and encrypted root file systems is that they made some changes. There's an additional package you now need (in addition to cryptsetup-initramfs) prior to updating your initramfs so it will mount an encrypted root: systemd-cryptsetup Despite what this says, I had to install it manually. https://www.debian.org/releases/trixie/release-notes/issues.en.html#encrypted-filesystems-need-systemd-cryptsetup-package

This doesn't exactly answer your question, but it may meet your need better... I experimented around with different fans & heatsink configurations. Using an official Debian image from Orange PI 5 Plus, I found that the PWM controlled fan changed speed pretty abruptly, and only at high temperatures. Their adjustment algorithm didn't apply any decent smoothing at all. It was very noisy, and the constant changes whenever I did anything made it very distracting. I ended up purchasing a 3rd party fan with two single-pin leads that I could connect to the GPIO's 3.3v (or 5v). And I have it mounted on a Geekworm case (N508 - made for the Orange PI 5 Plus), with a short heatsink over the ICs. That case had actually come with a fan that had a single 2-pin connector, so it was only good for 5v and about 5 months before it died. From the GPIO, the 5v is on all the time the computer is receiving power, but the 3.3v is only on while the computer is on. If you "shut down" the computer, the 3.3v shuts down along with it. When I first tried the new fan on 5v, it wasn't too bad, but I could hear it. If I ran it off the 3.3v (which I do all the time now), it's virtually silent. When I run something that maxes out the CPU for a long time, with this fan on 3.3v running (and the short heatsink in place), the SoC temperatures stabilize around 50 degrees, and I've never seen them exceed the mid-50s with this setup. That is way lower than that official PWM fan did with that pseudo-heatsink it's mounted on, under the same CPU load. And I never have to worry about the fan quitting if some software PWM control malfunctions. Here's that new fan I bought (it came in a pack of 4): https://www.amazon.com/dp/B08R1CXGCJ?ref=ppx_yo2ov_dt_b_fed_asin_title If you have an N508 or similar type of case, the fan mounts to the top of the case. I checked, and Geekworm is apparently no longer selling that case? But back when I was looking into all this, I had found another very similar case sold by a different company (after I'd already purchased the N508) - I don't remember its name. But the fan it came with came with two single-pin connectors like the fan I eventually ended up staying with.

@LanMarc77, I think you meant to tag @laibsch there What you're saying sounds like it could be a good option.

You can also build from the release version, though I'm not sure it's fully that version for everything since the build process downloads updates from the internet. https://github.com/armbian/build/releases/tag/v25.8.1 At the top of that page, you can see how many commits have been added to main since the release of v25.8.1. You can download the source code at the bottom where it says Assets.

I'd read rumors that uBoot has the ability for a multi-boot menu, but I was never able to get any video out of it to my DVI monitor to explore that too deeply. What I ended up doing was installing this UEFI port, and booting from it (instead of uBoot): https://github.com/edk2-porting/edk2-rk3588 The built image is about 6.6 MB, but the image actually uses 9 MB:. It consists a GPT table for a 16 MB device, plus a portion of an 8 MB partition (no flags) who's name must be uboot. The difference within the 8 MB partition is where it stores the user configuration settings. So I think the easiest and most secure way to flash the image is to first promote its size to 9 MB before flashing it to the microSD card or SPI-NOR (I've done each with good results): sudo dd if=/dev/zero of=final-for-flashing.img bs=1M count=9 sudo dd if=RK3588_NOR_FLASH.img of=final-for-flashing.img bs=512 conv=notrunc There are a few other versions of it for other hardware (other than rk3588). https://github.com/orgs/edk2-porting/repositories?type=all&q=edk2 That will boot UEFI and into grub very easily, and I do use grub to select which OS to boot into. I have one grub partition, and multiple installed OS partitions. The edk2 port is highly configurable, and recognizes hardware, including the network. Not sure if it's usable for remote access or not in its current build, but I think it can, at least, boot off the network. You can also configure a standard layout/path for your devicerees and overlays, where it will load them, but I haven't tested that out yet. If you don't override in the edk2 configuration or in grub, it will use the Vendor or Edge kernel's devicetrees (built in), or ACPI (also built in). Btw, I built it last night with a tiny change I made to the Orangepi5-plus edge devicetree to re-enable the ES8388 audio, and tested it out in Trisquel 12 with its kernel (with the devicetree from edk2) - it worked! The great thing is - their git clone and build process puts ALL the source files on your computer, so you don't need the internet to build, and you can know that any changes you make in the source code won't be "updated" overwritten by the build process. I've found with Grub, the update-grub utility will not find and add devicetrees, so you have to do that manually or hack in (which is what I've done). But again, apparently the edk2 port would make that unnecessary. So to add to the resources already mentioned, the edk2 port is open-source - they did it. Btw, I have also read that uBoot can boot grub directly, but I think you have to supply it with the address to load it into. Without knowing what I'm doing (when I first got my SBC), I didn't want to touch that.

Additional Info: The "Current" Kernel I found the equivalent code in the Current kernel. It is a clearly a different version of the file, but it looks like the same error is present. I have not tested it. Snippet Source: ./build/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts &analog_sound { pinctrl-names = "default"; pinctrl-0 = <&hp_detect>; simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; // This line here: Change GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH simple-audio-card,widgets = "Microphone", "Onboard Microphone", "Microphone", "Microphone Jack", "Speaker", "Speaker", "Headphone", "Headphones"; The "Vendor" Kernel I found the equivalent code in the Vendor kernel's devicetree. It is also a clearly different version of the file from the other two kernel trees. But it looks like this particular coding error (for the audio) is not present here. The headphone detection level is set to GPIO_ACTIVE_HIGH. Source: ./build/cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts However in my experience (tested again just now with version 28.5.1), the Vendor kernel seems a bit crippled: No GPU or video acceleration, and no ES8388 analog audio whatsoever (not even at the ultra-low volume I was getting with the Edge kernel). At least the screen, keyboard, mouse, and ethernet works, but with no video acceleration the video is slow and clumsy. I suspect that the best place to look for the audio issue with the Vendor kernel is not to focus on the audio, so much as to focus on what broke on an apparently deeper level.

Well that's one thing that confuses me with Linux source code - is having so many different versions of the same file, how to tell which one: location, version type, and especially which repository. Thanks so much for acting right away to get this fix into the Armbian!!

Awesome! Thanks so much!! You're welcome! The kernel.org audio patch by Maud Spierings is as follows: Source: https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/ ./arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts &analog_sound { pinctrl-names = "default"; pinctrl-0 = <&hp_detect>; simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; - simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_HIGH>; simple-audio-card,widgets = "Microphone", "Onboard Microphone", "Microphone", "Microphone Jack",

I Did It! I Got It Working!! ES8388 Analog Audio Output Here's How (this is very easy to do): It just involves making one simple modification to the devicetree. Note: I did this with the Edge kernel. My guess is that it will also work with the Current kernel. You can also try the Vendor kernel if its devicetree has the same code. Update: I've addressed the Current and Vendor kernels in this comment below: https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/#findComment-225009 I manually applied this patch: https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/ If you scroll to the bottom where it gives the patch, the GPIO_ACTIVE_LOW needs to be changed to GPIO_ACTIVE_HIGH in the given section of the devicetree. Here's the simple / quick way to fix it, without having to go through any lengthy (re)builds. Modify the already installed devicetree file (/boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb). 1. Install the package: device-tree-compiler 2. Backup the original, and convert to .dts format as follows: # Go to your devicetree directory cd /boot/dtb/rockchip/ # Make a backup of your original devicetree: sudo cp rk3588-orangepi-5-plus.dtb rk3588-orangepi-5-plus.dtb.bak # Use device-tree-compiler to convert the file from the binary .dtb format to source (text) .dts format (ignore the warnings) sudo dtc -I dtb -O dts -o rk3588-orangepi-5-plus.dts rk3588-orangepi-5-plus.dtb # Safety-Check Part 1: Convert right back to .dtb format (another filename), ignore the warnings. sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dts # Safety-Check Part 2: Compare the newly converted file with the original. They should be identical (this command should produce no output) cmp -l rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dtb 3. Using a text editor in sudo mode, edit the source (text) file: rk3588-orangepi-5-plus.dts Search for this phrase: simple-audio-card,hp-det-gpios I should appear exactly once in the file. # Here is what that line looks like (for me): simple-audio-card,hp-det-gpios = <0x133 0x1b 0x01>; # This is that same line before original compilation simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; 4. Notice between the brackets, there are 3 values, separated by spaces. The third value is the value to modify from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH, or for us, from 0x01 to 0x00. 5. Convert your modified .dts file to a .dtb file (ignore the warnings): sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dts # Optional: Quick Comparison Check (this should output exactly 1 line with 3 numbers: [big number] 0 1) cmp -l rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 6. Copy the new fixed file to (overwriting) your original: sudo cp rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 7. Reboot (and have ES8388 analog audio out). Note: Whenever you do a kernel change or update, you will need to repeat this process until the Armbian kernel updates catch up with this patch. Here's the lengthier explanation (this is repeatable if you want to check it out yourself) 1. I downloaded the source code for version 25.8.1: https://github.com/armbian/build/releases/tag/v25.8.1 2. I extracted the archive and started the building process (./compile.sh) with the edge kernel (and a desktop image). It would not build because it rejected two of the kernel patches, but it did download everything into the cache. 3. I then found the file described in the patch: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts 4. In that file, I searched for the line indicated in the patch, just prior to the line to modify: simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; ...and found the appropriate section. I confirmed the line that followed matched the original (incorrect) version mentioned in the patch entry. 5. I then scrolled to the top of the .dts file and looked at the files #included, to find where the GPIO_ACTIVE_LOW macro was defined. I figured dt-bindings/gpio/gpio.h was a reasonable place to look first. I found it here: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/include/dt-bindings/gpio/gpio.h Near the top of the file were these #defines: /* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 6. See the simple fix above for the rest. Tags: @Werner, @Igor, @laibsch @dimaxus, @EricaLina, @ricardo_brz, @eselarm

It's already been my intention to do so.

Thanks, I am aware of that. But that's an Ubuntu that's using the barebones vendor kernel. I need a fuller kernel than that, and Debian. As it turns out, in looking at recent updates here, it looks like the audio issue has been addressed within the past few days, and that it's an easy fix (as I thought it would be): https://patchwork.kernel.org/project/linux-rockchip/list/ I have yet to try that out, but it looks like I can either wait for the update in the bleeding edge kernel (if it's not already present) or modify the devicetree myself with the fix they discovered.

Awesome! Thanks so much for this! I see they're addressing some key issues, such as NPU functionality and fixing the ES8388 audio issue with the Orange PI 5 Plus (the board I have). This is terrific!!

I have a different Orange PI board, but I have two partitiions of Armbian installed (25.8.1), one with the edge kernel, the other with the current (mainline) kernel. I checked my /boot/dtb/rockchip/ directories in each for the Orange PI 5 Pro, and there is a device tree for it with the edge kernel (rk3588s-orangepi-5-pro.dtb), but not with the current kernel. Perhaps a question would be: Is that devicetree (.dtb file) being utilized with the edge kernel? Might be worth looking into.

So 25.05 and 25.5 are the same version? That threw me off for a while...

True, it's not critical to compile the ideal kernel into the image as long as I get one that works, I can always update it later from within the image. But I do prefer to do things right the first time, and to be utilizing the version I think I am and intend to be using. Btw, I boot from grub as well. For my Orange PI 5 Plus, The edge kernel is the only one that's actually useful to me because the Vendor kernel has no GPU acceleration at all, the Mainline kernel has no video output to my DVI monitor, and all 3 kernel branches aren't correctly utilizing the ES8388 analog audio, which I need. The audio volume is barely audible even when all volume controls are maxed out. It's been that way in every operating system I've tried (except those with old barebones Vendor Kernels from Orange PI). So ultimately I want to compile the latest (relatively) stable edge kernel myself, so I can modify the source code in an attempt to fix the audio, and of course share the solution when / if I find it. I've already found that the ES8388 and ES8328 are compatible - hence the es8328 modules used in the kernel for the ES8388. And I've narrowed down where the issue most likely is: Directory: sound/soc/codecs Files: es8328.h, es8328.c, es8328-i2c.c