jock

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!

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.

@incbot just use a fresher image rather than a two years old one: https://github.com/armbian/community/releases/tag/25.5.0-trunk.444

I don't see any driver written with your name. Can you share that?

If you think it is so simple and you say you're so capable, do it yourself. Point me where your contributions to the project are and I will take this post seriously.

At the moment there is no driver for the mainline kernel to drive the analog output, so no composite output unfortunately. The driver in the vendor kernel does not seem very complex, but yet noone has ported it to mainline kernel.

Hello, you may want to edit the device tree and turn off the mmc@... node where the sdio wifi chip is connected. You may find it easily looking for supports-sdio property, then switch status property do disabled

Added support for Debian Trixie (only for arm64)