Werner

Something isn't right, agree. Needs investigation. Until then feel free to use any mirror from here: https://docs.armbian.com/Mirrors/ For armbianmonitor you can use this workaround until we can get that one properly back up too: PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u paste.armbian.eu works too.

I suggested to split 5 and 5B again since one works well, the other not. If it cannot be fixed consequence will be dropping it to csc or eos.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

That's quite odd since this is the exact 3rd party driver Armbian ships with its images. An older commit though. Needs to be tested if it can be pushed.

Unless OP is using EDKII there is no bios on RK3588 boards in general. We include this driver already? https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh#L292

Depends on board. Some vendor hard-wire leds, other allow software control.

A fix was recently implemented to avoid kernel panic. Try building an image by yourself or use automated images from github.com/armbian/os or github.com/armbian/community

Yes. This patch has been sent upstream and is awaiting either rejection, correction or acceptance. Without reading through it properly I assume this is an attempt to fix the initial issue with the ethernet ports.

As mentioned it might be possible or not. Depends on board. Check /sys for keywords led and trigger. cat the trigger file/s to get an idea what values it accepts.

send pr. https://docs.armbian.com/Process_Contribute/

There are multiple lines starting with overlay= Put all in one line like overlays=uart1 uart2 uart3 uart4 i2s i2c whatever Make sure the enabled overlays don't share same GPIO pins. Check your boards datasheet/manual.

I noticed it is applied somewhere between the existing patches. Have you tried to rename it to something like zzzz_yourpatchfile.patch so, since they are ordered alphabetically, it is applied at the very end, just like your chances have been made with all the previous patches already applied.

Maybe this is why:https://patchwork.kernel.org/project/linux-rockchip/patch/20241220163227.1501912-1-alicja.michalska@9elements.com/

moved If it is a 1:1 clone of opi pc check if i2s overlay is enabled. Try armbian-config or the manual way by setting in /boot/armbianEnv.txt Check /boot subfolders for available overlays.

There is no package simply called qemu: https://packages.debian.org/search?keywords=qemu&searchon=names&suite=bookworm&section=all

Debian has some weird behaviour when using "su" because $PATH lacks /sbin for whatever reason. /sbin/chroot instead of chroot might work

If somebody adds support for it, why not? https://www.cnx-software.com/2024/12/21/rockchip-rk3588-mainline-linux-support-current-status-and-future-work-for-2025/ tl;dr: even if rk abandons it seems like collabora will continue.

Isn't the hdmirx on rk3588 able to do 4k60? https://www.rock-chips.com/uploads/pdf/2022.8.26/192/RK3588 Brief Datasheet.pdf

Should be rk3588-hdmirx.dtbo

moved

hdmirx is disabled by default since the code is poorly implemented and causes load for no reason. If you still want to play with this enable it via overlay.

Best chances is getting yourself familiar with the build framework and try to port the necessary patch to 6.12.y What I'd do is probably using kernel-patch command along with ./compile.sh (like "./compile.sh BOARD=udoo BRANCH=current kernel-patch") and then manually adding the patch contents. Then copy over the newly created patch into patch/kernel/archive/imx6-6.12 and try to compile. If it works try booting and see if USB are back again. PR is welcome Did a look myself and it seems like it's not that simple. the dts looks good already. But the drivers/usb/misc/onboard_usb_hub.c file is gone entirely. Therefore I guess CONFIG_USB_ONBOARD_HUB=y doesn't make sense in the kernel configuration either. Ahaa, there we go. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/misc?h=v6.12.13&id=31e7f6c015d9eb35e77ae9868801c53ab0ff19ac So things need adaption to the new name

That's what you get with bleeding edge. Use vendor if you need stuff working. Here is great overview of what is working in mainline: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

I guess the patch has not been carried over to 6.12 since the folder is empty: https://github.com/armbian/build/tree/main/patch/kernel/archive/imx6-6.12

Yes. Tools like etcher or USBimager can decompress images on-the-fly. dd cannot do that. Latter since the image may already contain partitions, depending on board. Not really. If it is big enough to fit the image it is good enough. However microSD cards with bigger size are usually a lot faster as well. I personally use and can recommend sandisk extreme (the golden ones) with either 32G or 64G capacity. Too large is also possible since the SoCs may have a limit. So if your SD card is 2TB or something...try something a little smaller it never occurred to me that I had to install any kind of dependency to use it. Strange. Maybe there is another option available: https://gitlab.com/bztsrc/usbimager