Werner

There is also oldarchive: https://fi.mirror.armbian.de/oldarchive/odroidm1/archive/

Try an image with mesa-vpu extension present or build one. I think that ships a modified version to make use of hw acceleration better than stock.

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

Maybe firmware packages are frozen? Check with apt-mark showhold

agree, this doesn't make sense. Though I also wonder why it should not be included by default. I never ran into this issue and tried several minimal images on various boards...

Hi The logs you provided (besides that they're incomplete) are from u-boot and have nothing to do with OS level. it might be possible that u-boot supports the 2nd NIC but it is broken in kernel. Could be a device tree issue, could also be something else. I suggest to try the available kernel branches (legacy, current, edge) first to check if one of them works properly. You can use armbian-config to switch between kernels or swap sdcards with written Armbian images with various kernels beneath on. @jock has some insights in some older rockchips I think?

There is no log level 8. 7 is max https://linuxconfig.org/introduction-to-the-linux-kernel-log-levels

title updated to something that is actually useful

Latter.

Kernel versions might differ depending on hardware since board families have individual patchsets which might require specific Linux versions. If it is the same board then I think current has been bumped from 6.6.y to 6.12.y recently. You can try legacy instead if you need 6.6.y version. It is not possible to build a specific version like 6.7.2 because the patches Armbian puts on top of mainline kernel are following recent versions which means sooner or later some will break compilation. If you need a specific version you are on your own to specify the version necessary in the board configuration and fix issues that might occour.

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.