Please give me a tip - what is purpose of /dev/mmcblk2boot block devices created? Quite small size - 4MB - ones, do they serve to something u-boot needs at boot time? There are no records for them in fstab so I assume they are created by zram, but what happens to them after boot when they aren't needed anymore? Board Orangepi 3LTS with bookworm minimal Also as a matter of wondering - why there are two zram devices: one of 1/2 of RAM (as usual) and another of quite small 50MB only, what is it for? root@heaven:~# fdisk -l <redacted> Disk /dev/mmcblk2boot0: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mmcblk2boot1: 4 MiB, 4194304 bytes, 8192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes <redacted> Disk /dev/zram0: 987,53 MiB, 1035497472 bytes, 252807 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes

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. 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 textual .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 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] 1 0) 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.

@Nick A sorry, i haven't got any information about the axp chip, i will do the reseacrch

@Ducdanh Nguyenthe secure boot patch is safe it doesn’t burn any fuses on your SOC. you still haven’t answered the axp chip question. If it doesn’t have one then it’s not a h313. The newer allwinner SOC’s use a axp chip for power management. If I don’t have that information then I don’t know which image to recommend.

@Nick A oh yea i used aida64 all the time (and with alot of command line commands), that's where i came up with h313 since it uses cortex-a53, the clock speed and the arch is 64bit armv8 (on 32bit mode) and about the secure boot patch, i think it's too risky (since it is a fake box and diffrent dram settings, etc,....) and i think i will buy a cable and test the su command, if it works, i will dump the boot.img and extract it