Werner

since the full boot log is missing in armbianmonitor output can you check or provide (like from kern.log) if the uart devices are actually loaded or mentioned during boot? overlay prefix and names looking good.

Would you mind providing me with the contents of /boot/armbianEnv.txt?

Unfortunately no. But this is basically what happens while building when this extension is enabled: https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh

At this time I bet it will work better with vendor kernel since it is close to feature-complete while mainline is still under heavy development. But well, worth a try I guess.

Hm this is odd. Is there a specific reason to use mainline? If not you can try a vendor kernel based image. Overall I cannot reproduce. I have an Orangepi5 here and usb works well with both vendor an edge. Latter I tested earlier today with kernel 6.14.0-rc2 Also check that your board does not suffer from undervoltage. Ideally use a PSU that outputs slightly over 5 volts in order to compensate for losses across wiring, connectors and pcb traces.

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

https://github.com/armbian/build/pull/7845/files#diff-0b37fc9a30f903883decd1c4213234082968ebedb7b4a9c52bc940f2407c4464R1

Ah. A quick test revealed that the overlay name causes it a file not found. Go to /boot/dtb/rockchip/overlay folder and rename rk3588-ov13850-c3.dtbo to rockchip-rk3588-ov13850-c3.dtbo Then reboot. To get to the root cause of this at least read access to the boot loader is necessary. Therefore everyone tinkering with SBCs should have an USB UART adapter handy.

Have you tried pre-built images? https://github.com/armbian/os/releases/tag/25.5.0-trunk.90 Edit: Ah, no edge images available. Could you please test this one? https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.05.0-trunk_Orangepi5_bookworm_edge_6.13.4_minimal.img.xz

Seems like your /boot/armbianEnv.txt is wrong Looking like this I assume? verbosity=1 bootlogo=true console=both overlay_prefix=rockchip-rk3588 overlays=panthor-gpu fdtfile=rockchip/rk3588s-orangepi-5.dtb rootdev=UUID=af265968-c707-4182-9419-ca767922fd72 rootfstype=ext4 fdt_overlays=rk3588-ov13850-c3 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Try something like this: verbosity=1 bootlogo=true console=both overlay_prefix=rockchip-rk3588 overlays=panthor-gpu ov13850-c3 fdtfile=rockchip/rk3588s-orangepi-5.dtb rootdev=UUID=af265968-c707-4182-9419-ca767922fd72 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

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

There is a major discrepancy. This is what it ideally looks like'ish: Interestingly the 3B seems to have some sort of rtc but I assume its worthless without a puffer battery connected. At least a connector for such is there.

Since this is userspace any Debian or Ubuntu manual how to do that should work: https://www.google.com/search?q=debian+set+time+and+date

Hi, I don't know the internal mechanism of the forum software but I guess its just fine. Thanks for letting us know though. Cheers

If the time offset is too large things like ntpdate might not work. Try setting manually. Also check date. Most sbcs don't have something like an RTC module or a battery to keep date.

https://github.com/armbian/build/pull/7856

Make sure your time is properly set.

Try building an image with vendor kernel and mesa-vpu extension enabled. Not sure if a pre-built one is available.

That seems like sw from vendor. eMMC onboard memory needs to be erased. Check docs, I don't know by heart how to do it. Maybe there is some pin that can be shorted to ground to disable it. Or there is some tools or flash mode to erase/skip it. Once eMMC is nuked booting from microsd should work just fine.

https://debug.armbian.de

Good to know. Moved to off-topic.

please test again.

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.