jock

@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!

What wifi do you have? Did you run rk3318-config to configure the device tree overlays for your board properly? The intent of rk3318-config script is to avoid the users tinkering with the DTS, but requires to know the board name printed on the silkscreen of the board itself. The commercial box name, instead, is often useless or misleading.

@remlei you can see from the u-boot log that the overlay is not applied because there is the rk322x prefix two times. The overlay must be set literally as usb-otg-peripheral as I wrote above, and not rk322x-usb-otg-peripheral: the rk322x prefix is added automatically. About the OTG functionality, as said your mileage may vary. Unforturnately the rk322x OTG port or driver does not seem to be very collaborative or totally standard compliant.

@remlei last time I checked, the usb gadget overlay was working fine and the UCD device was correctly spawning up. Some things work with rk322x (mass storage), some others don't (UAC1, UAC2), so your mileage may vary. Verify you have usb-otg-peripheral in /boot/armbianEnv.txt in the overlays= line

@Vinicius Guastala I agree with @fabiobassa, thanks for the very detailed post of your board and broad description of the behaviour. I would suggest you to erase the internal flash and try to boot from sdcard with this armbian image. It is an "experimental" image with opensource Trust OS; many recent boards are having issues with proprietary trust os, possibly yours has similar issues, so you could give a shot to this. By the way, the serial log output would be indeed very handy if you have the chance to find the serial port. Beware also that armbian (and multitool) use 115200bps baud rate for the serial, while proprietary software uses 1.5Mbps baud rate!

@gurzixo much better to steer to an officially supported SBC from armbian, if you need something reliable: https://www.armbian.com/download/?device_support=Platinum support&arch=aarch64

Yes, but use a flash device as swap is the worst idea you can have

The only way, which is really discouraged and discontinued, is to use a build with legacy kernel. On mainline kernel, the only driver supported is for ssv6051p, but it does not work for ssv6256p. There could be several reasons the eMMC is not detected. One of the reason is obviously it is the broken, even though the DDR part is still working. More often the board has some circuitry or the chip has some configuration that need to be tuned properly in software to work. Tv boxes have plenty and plenty of different configurations that is impossibile to cover all the compatibility issues that may arise. If the flash part of the eMCP is really broken, if you plug an sdcard with Armbian on it, the stock Android should not boot (obvious if the internal flash is broken) and Armbian should boot instead. About the MSN8800D, it seems to be a clone of AIC8800D chip, of which a driver is circulating and should already be integrated in armbian, but not yet enabled for rk322x.