mitu

Unreadable squiggles - again AI generated ?

Unreadable squiggles - AI generated ?

Ah, I think I know why I didn't 'find' it - trying to run the command as regular user didn't work since it's in /usr/sbin and this path has been removed from the $PATH of regular users. I need to be root in order to have it available. @Werner thank you again for the pointer.

@Werner The overlay solution worked - thank you ! Is armbian-add-overlay a separate package/command ? I managed to enable it by creating a rockchip-rk3588-usb-host.dts file in the /boot//dtb-7.0.5-edge-rockchip64/rockchip/overlay folder, compiling it to ockchip-rk3588-usb-host.dtbo with the device tree compiler (dtc) and then using armbian-config to enable the loading of the usb-host overlay.

OK, I checked and the USB port is already set to host: The USB-A port is still not functional, but - as said in my previous reply - the USB-C port is working fine.

Not really. The USB-C port does work, I actually connected an USB hub to be able to add a keyboard/mouse to the SBC and it worked without issue. I'll try this , thank you for the instructions. The USB-C port does work though if I connect a hub to it, I'm able to use the devices connected to the HUB without issue.

@tim zeng sure, but that's not - directly - related, since the Orange PI5 and the Orange Pi3 are different SOCs/SBCs. The only common trait is the poor SW support offered by the vendor.

Hello, I have installed the Armbian 26.2 minimal IOT image based on Debian 13 Trixie - with the 6.18.x kernel - and I noticed the USB2 port (the single, vertical port next to the Ethernet port) is not working. Is this a limitation of the mainstream kernel (6.18.x) - i.e. does this work only with the vendor kernel (6.1.x) ? NB: I upgraded to 6.19 using the 'edge' kernel, but I'm seeing the same behavior. Here's the armbianmonitor outpur - https://paste.armbian.com/raw/udefojuxuk

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.

Here's the output, shows PCMs for both the HDMI and analog audio outputs: > How do you test the HDMI sound ? speaker-test or aplay (with a .wav file).

The kernel version reported by armbianmonitor (see my first post) is 6.16.4-edge-rockchip64.