mitu

OK, so that went reasonably fast and produced the 4 kernel debs. The linux-libc-dev-edge-rockchip64 didn't install due to conflict with the (current/stable) linux-libc-dev package - I think this is expected - but the rest of the kernel packages have been succesfully installed and the dkms error seems resolved.

Eh, I can try the 7.0 rc package and see how they behave, as long as it's 6.19 or later is fine. Thanks for the pointers.

If I'm building the .deb file manually, is there a way to build with kernel 6.19 for the OrangePi5 ? Can I use the edge branch (instead of current) for this ? While I don't mind waiting for the package to build, if I can build the bsp/kernel/headers for 6.19 I can give it a try. EDITED for formatting.

Hello, I have installed the minimal Trixie based image for Orange Pi5 (the image named Armbian_26.2.1_Orangepi5_trixie_current_6.18.8_minimal) and then attempted to build an out-of-tree kernel module. Having installed dkms and build-essentials, plus the kernel headers through armbian-config, I found the headers package hasn't been fully set-up, the build symlink in /lib/modules/<KVER> is missing and dkms complains that the kernel headers for the kernel are not installed. The kernel headers are installed though, but it looks like they're from a previous release (25.11.2 instead of 26.2.1). # dpkg -l | grep rockchip ii linux-dtb-current-rockchip64 26.2.1 arm64 Armbian Linux current DTBs in /boot/dtb-6.18.8-current-rockchip64 ii linux-headers-current-rockchip64 25.11.2 arm64 Armbian Linux current headers 6.12.58-current-rockchip64 ii linux-image-current-rockchip64 26.2.1 arm64 Armbian Linux current kernel image 6.18.8-current-rockchip64 It the headers package still pending packaging ? Shouldn't armbian-config provide an error in this case and not install the old kernel headers ? EDIT: armbianmonitor ouput - https://paste.armbian.com/oliyalebeq

@sunshine sorry it didn't work, I though the upgrade for `raspi-firmware` would force the uninstallation of the (outdated) libs, but this doesn't seem to be the case.

Where did you hear that ? Note that the 'firmware' package is not updating the EEPROM that's present on a Pi4/Pi5 and I had no booting issues updating the raspi-firmware package on RaspiOS.\ Of course you could make a backup if you want to feel safer, but I have no reason to believe there's anything that's going to cause issues if you're going to upgrade the raspi-firmware package.

Try an apt full-upgrade. The libraspberrypi packages have been deprecated recently (e.g. June/July) and recent RPI packages shouldn't depend on them, including raspi-firmware.

Try the 'minimal-iot' flavor, I think that's the only one that boots from the current images. You can then add the desired packages and even switch to the 'edge' kernel from armbian-config.

@Fredrik thank you for testing.

@Fredrik thank you for the reply. I wonder what's Gnome doing to initialize the audio that's different from a regular (non-graphical) boot. FWIW I installed also Pipewire/Wireplumber and tried to test the audio through the PW ALSA emulation, but that didn't work either. Just out of curiosity, does speaker-test work from the CLI once booted into Gnome or is it just the sound test in Gnome settings that's working ?

OK, so I installed the latest Debian/Trixie + Cinnamon + vendor kernel available and audio is working. The name of the cards and mixers are different though: speaker-test worked both by specifying the mixer (... -D plughw:CARD=rockchiphdmi0,DEV=0) or through PulseAudio's ALSA emulation after setting the default sink to the rockchiphdmi0 card. The list of audio cards is different in the vendor kernel than what's available OOB with the edge kernel, so I'm not sure if the configuration is comparable. But the audio port/cable combo seems to be fine so there's that..

I can try it, just to check that the cable/port combo is ok. I'm not sure how would that help - the reason I'm using the edge kernel is to use the upstream/Linux kernel implementation and the implementation may not be the same as the one provided in the outdated vendor image.

I haven't tried the vendor image, but I have another SBC (RasPi4) that can succesfully output audio through the monitor speakers, so the monitor is ok. I could re-test the HDMI cable I guess, but since the video signal is ok I don't expect the audio to have issues.

It doesn't seem to make a difference:

Sorry I mean Which kind of output device: TV, Monitor with build in speakers? I have a HDMI monitor with speakers included. Yes.