The Tall Man

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

I've downloaded the latest stable Release of the source code: https://github.com/armbian/build/releases/tag/v25.8.1 When doing a Build, when it allows you to select the kernel branch: [vendor, mainline, edge], the only edge available for selection is the bleeding edge (i.e. latest trunk version). I've downloaded the 25.8.1 source code, and that's the edge version I want to compile. How do you build an image with the latest (relatively) stable edge kernel, as available in Armbian-Config? (i.e. currently v6.16.1-edge at Armbian 25.8.1)? Update #1 When compiling the image with the edge kernel, it downloaded it from the internet and it took roughly an hour to build. When compiling an otherwise identical image with the Vendor kernel, it did not seem to download it from the internet (although I wasn't watching it closely), and it took roughly less than half the time to build the image. The reason I compiled an image with the Vendor kernel is because something broke in the last 24 hours on the internet-supplied edge kernel. It compiled 24 hours ago, a few hours ago it didn't. This wouldn't be an issue if it was compiling the most recent release of v6.16.1-edge (25.8.1), as per my intention, instead of the ultra-latest. I also made some discoveries about version number inconsistencies (independent of the kernel branch selected). Things are confused. In Release 25.8.1, the version is 25.11.0.trunk. In Release 25.5.1, the version is 25.08.0-trunk.

Thanks!! Thanks for the overview. ES8388 Codec Driver Something to add to my previous comment here (2 comments up). I've noticed that, with the edge kernel, ALSA calls the ES8388 the 8328 instead. I've also seen the 8328 referenced in the devicetree .dtb file (via a hex viewer). I happened across where it appears to be, in two repositories: https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/sound/soc/codecs https://github.com/torvalds/linux/tree/master/sound/soc/codecs In both of those directories, there is an es8328.c, es8328.h and other es-... numbers in that range, but no es8388 file. To any developer reading this, it might be worthwhile to create es8388.h and es8388.c as copies of their respective es8328 counterparts, then have the es8388 files used in the build and referenced in the devicetrees instead of the es8328. This would create the clear (and correct) workspace to make the necessary modification(s) to fix the issue (of the volume apparently being right-shifted by 7 or 8 bits - re my previous comment). I've noticed in the es8328.h file, there are several configuration constants defined. It could be as simple as modifying one of those in the es8388.h to match the actual es8388 codec. Hardware Datasheets / Schematics While these are likely more low-level and off the path than practically useful for the simple fix that's likely needed here, it's good to have the datasheets available in one's toolbox: Everest-Semi (ES) Hardware Datasheet For ES8388: http://www.everest-semi.com/pdf/ES8388 DS.pdf Orange PI 5 Plus Schematic: I don't see how the way they have this schematic formatted would be of much practical use to anyone, but the ES8388 is on page 29. I didn't find any interface between it and the RK3588 there or on any other pages. There's a link to the schematic on this page, under Official Resources: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-5-plus-32GB.html

ES-8388 Analog Audio Works At Fractional Volume (a possible solution) The issue of no ES-8388 analog audio output has been dragging on for months, and in all three kernel flavors (vendor, mainline, edge). I've discovered, at least with the latest edge kernel (as of Armbian 25.8.1 today), that the audio through the ES-8388 IS actually coming out, and the sound is clear. It's just that the volume that can be heard is extremely low and barely perceptible if all volume controls are maxed out and the audio file itself is at full volume range. This Bug Is From The Kernel / Driver Development Before It Gets To Armbian This is not new, I'd discovered this earlier and on other operating systems as well. So I know the issue is coming from the kernel / driver development, before it gets to Armbian. My Thought: The Audio Is Bit-Shifted by 7 or 8 bits I would venture an educated guess that the audio is 1/128 or 1/256 the correct levels (i.e. bit-shifted by 7 or 8 bits). This could be caused by, for example, a 24-bit audio integer value being copied into a 32-bit integer buffer without bit-shifting by 8 bits to align the MSBs (most significant bytes). The sign bit could be why it may be 7 instead of 8. The Easy Fix (for someone familiar w/ the source code) If this is the case, then someone familiar with the source code, who knows where this is - it would be a real simple fix. On Fedora KDE, I was able to crank up the volume even beyond max settings to try to make it louder, and it got clamped instead. My thought is that this confirms that the issue is the final mix is going to the device, which would make sense.