jock

Hello! You should really look to the board name in rk3318-config rather than relying to led-conf numbering; also your dmesg is showing a very bad error which is probably due to an unstable system rather than a bug

rk322x armbian images never used the offset of 8192 sectors, only the multitool has such offset to increase compatibility with stock images

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality. The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271 Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

@MattWestB According to /boot, your box should boot 6.16. I don't know though if you have other eMMC/sd/USB devices which may interfere

Normally not if you have a recent distribution. Beware not to test that kernel in a box that does something useful though!

@MattWestB@Thiên Thư Lục In this directory I have put an experimental kernel with a kernel patch that should fix some USB3 issues. If may want to try and experiment if it works for you. It is based upon kernel 6.16. You only need to install the image and dtb packages, headers are only if you need to compile some thirdy party drivers.

@robertoj --hwdec=v4l2request seems present on mpv v0.40, which is the one in trixie. Older mpv versions have --hwdec=drm; I don't know the differences, but I guess drm become v4l2request at some point. --gpu-hwdec-interop=drmprime-overlay directly presents the frames using an hardware overlay. It is very useful if you want to go fullscreen (like on a virtual terminal), but if you are running a desktop environment, everything behind the video overlay will be hidden. --gpu-hwdec-interop=drmprime instead uses the linux facilities (dmabuf) to transfer the decoded frames from the hardware decoder buffer to the EGL/OpenGL (or whatever) presentation layer without actually copying the buffer data, but just passing a file handler. It is more complex and has more overhead, but it is suitable to be used within a desktop environment because the frames are drawn in regular windows. --gpu-hwdec-interop=auto don't know, I guess mpv does some guessing to decide which one is the best.

It looks like mpv does not work anymore with v4l2request on trixie. Benchmarking with ffmpeg reports very high framerate on a 1080p h.265 video, but mpv refuses to work when --hwdec=v4l2request is chosen. It says a generic [vd] Could not create device. message in the log and switches to software rendering. Parameter --hwdec=v4l2request-copy works though, despite being slow because it involves framebuffer copy.

Hello Then you're doing it wrong. Bypassing the eMMC shorting the CLK pin to ground will definitely force the boot from sdcard, or fall into maskrom mode if no sdcard is in the slot. I wonder what debug info is prompted on the serial port (if any) and if the device is recognize if you connect the OTG USB port to a PC with a male-to-male cable

Then Trixie arm64 is already supported BTW: just managed to use a trixie armhf armbian rootfs as a rootfs container for lxc... it just works, so packages are coming for trixie armhf too 😁 edit: trixie armhf packages added!

Unfortunately, lxc containers are not supplied anymore for armhf targets (see https://github.com/lxc/lxc-ci/commit/8d7326930f824a0aeedb6be3598c64e9e9a6ce36, I read somewhere the build machine has no 32bit compatibility anymore), hence building ffmpeg on Debian Trixie for armhf (32 bits) requires some more trickery.

Hello! Asus Tinkerboard is still perfectly supported by Armbian. Best setup is the current LTS kernel 6.12, you can take an image from the official download page: https://www.armbian.com/tinkerboard/ enjoy!

Probably your issue is the proprietary trust os that is shutting the system down in a sort of suspended state

@usual user thanks for the info!