While doing various tests, also other bootloader than EDK2-UEFI v1.1 that I had in eMMC, I discovered that with 2026.01-rc2_armbian-2026.01-rc2-S365a-Pa203-He3cc-V062a-Bbf55-R448a kernel 6.18.0-rc7-edge-rockchip64 did not find/enable audio via HDMI.

I moved the computer to other room where I rely on the speakers in the monitor, else I would not have discovered it as I also use networked pulseaudio.

 

What works is 2025.01-armbian-2025.01-S6d41-Pdb4b-H2194-V062a-Bb703-R448a, so sort of last-known-good, got that via:

sudo apt install linux-u-boot-nanopi-r6c-current=25.8.1 and wrote the binary with dd to eMMC

 

Another issue is that the monitor does get out of sleep too late, so the loglevel=7 effect can only be seen on extra serial console, whereas with the UEFI bootloader, the HDMI gets always initalized properly, so before kernel is loaded.

 

Note that this is with booting via grub. So with EDK2-UEFI v1.1 bootloader, I get a normal Debian graphical kernel selection menu, like on x86-64. With Opensuse Tumbleweed it is slightly different, as that also automatically duplicates on serial console (if 't' is pressed , from 'text'). So this is actually quite ideal. The only disadvantage is that it does not want to store boot entries (but works on ROCK5B in SPI-flash).

 

I probably need an own build on SD-card first to see how 2026.01 (or later) can do the same as EDK2-UEFI v1.1 more or less.

 

I should note that with EDK2-UEFI v1.1 bootloader, I do not load the DTB that comes with the kernel version. I used the setting 'vendor' or 'mainline' in the UEFI settings, that gets stored well actually. Now with the 25.8.1 U-Boot, I manually added a devitree loader line in grub.cfg, but that will be overwritten, so need to see what makes sense.

 

I find the lack of GRUB via HDMI too problematic, so I put EDK2-UEFI v1.1 in eMMC again. I needed to wipe it completely, just writing the part without partition table normally done for U-Boot kept using the 2025.10 U-boot that was written there. I do not know how that comes. 

I know EDK2-UEFI v1.1 will divert to SD-card, so I though I use that to test U-Boot again. 

 

- blkdiscard SD-card

- write  U-Boot SPL 2026.01-rc2_armbian-2026.01-rc2-S365a-Pb445-He3cc-V062a-Bbf55-R448a (Dec 03 2025 - 04:31:42 +0000)  to it

- type reboot

 

After restart and desktop login no HDMI audio. Kernel log showed long series of audio driver related errors
- shutdown and pull USB-C powerplug

- plug it in again and let it boot
- then no audio error and also hear a 'plop' in the monitor that means the audio is enabled/working

 

So it seems something does not reset correctly, so powercycle needed, while HDMI monitor is kept powered and HDMI cable stays connected all the time.

 

What is different now:

- kernel 6.18.0-edge-rockchip64

- eMMC contains  EDK2-UEFI v1.1 and passes control/boot to SD-card U-Boot

 

But I think it is the powercycle that is the key thing.

An interesting new feature of the 2026.01-rc2 U-Boot is that the CPU clock go down to 480 MHz when mainline kernel, was 1GHz. Is not lowering idle power though, is 3 W, is 1.5 W with vendor kernel. Not clear why that is.

 

Edited December 10, 2025Dec 10 by eselarm

A new trial with:

 

U-Boot SPL 2026.01_armbian-2026.01-S127a-Paca4-He05b-V36ee-B5da4-R448a (Aug 14 2026 - 13:26:35 +0000)

 

on otherwise blank SD-card has audio; (EDK2 UEFI v1.1 still in eMMC)

 

Tested kernels:

7.1.12+deb14-arm64-16k

7.1.8-edge-rockchip64

7.3.0-rc2-bleedingedge-rockchip64

 

All 3 do audio, so case closed I would say. I also did a small modification to  /etc/grub.d/10_linux  such that a devicetree statement is used per kernel version, just using the .dtb from kernel package on rootfs. Needed a bit of a trick/symlinking as the new Debian Sid kernels store DTB files on other place than Armbian/Debian13.