jock

Thanks! For @Victor Picinin the temporary working URl is https://stpete-mirror.armbian.com/users.armbian.com/jock/web/rk322x/armbian/beta/Armbian-unofficial_24.11.0-trunk_Rk322x-box_noble_current_6.6.56_xfce_desktop.img.xz

@Virgilio Junior you can use multitool, and use the "jump start" installation: you should be able to boot from sdcard and USB as well without doing the process by hand. Forget about the NAND, it causes troubles you would not deal with

uhm, there is misconfiguration in the server actually; I see users.armbian.com is serving the certificate for stpete-mirror.armbian.com, perhaps @Igor can fix the issue

Found with google: https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/96/#findComment-218361

In theory, it shouldn't

Mmmh, the easiest thing you can do you can build an armbian image taking rk322x_tee_os.bin from this branch in my repo and overwrite rk322x_tee.bin in the same path of your armbian copy, then build a regular image which will have an opensource TEE and should have no issues anymore. Actually you could even reinstall u-boot without reinstalling the whole system, but it is just a tiny bit more involved. If you can restart from scratch, rebuilding the image with opensource TEE is easier.

Multitool uses the proprietary miniloader blob for booting and it does not work with opensource OPTEE unfortunately. I guess the issue is related with this patch that allows mainline opensource u-boot to support proprietary Trust OS, but that's just an ineducated guess.

Hello @Victor Picinin yes the problem is exactly a watchdog in the proprietary trust os. Some people have issues after 60 seconds, others after 30 seconds and others after 30 minutes. Being the proprietary Trust OS closed source, we can't know what is happening. I suspect it is a sort of automatic "suspend" feature of some sort, but can't be sure because digging into practically is diffucult. What is sure is that if we use OPTEE Trust OS compiled from open sources (OPTEE is the base for the proprietary Trust OS too), there are no issues of sort, but we lose some features like DDR3 memory scaling and "virtual power off" (a suspend mode that can awaken the board via IR-control; there is a driver and a device tree overlay for that to work in armbian)

Yes, or at least there should be less chances to hit some corner case that reduces the compatibility. LibreELEC is using the mainline kernel only for years though, so it is really strange you have issues with both armbian and multitool. I may wonder there is something odd in the device tree, but it would be odd that a misconfiguration in the device tree causes a kernel fault in the DRM code and in particular in the wait for vblank function 🙄

Very weird HDMI is not functional in both armbian and multitool: they use very different kernels. Multitool uses the 4.19 vendor kernel, which should be supposed to provide "best" compatibility. The dmesg error is highly related to the missing HDMI, but in a way I can't recognize. About the VFD driver, I guess you're using OpenVFD driver. Latest kernels (both 6.12 and >= 6.16) come with tm16xx driver which is by far much much better and candidate to be upstreamed in the mainline kernel. Here is the github project reference; the driver is already compiled in the kernel, but you may need to edit a device tree overlay by yourself to let it work with your board. To try some debugging, the complete dmesg output and the original device tree of the stock android firmware would be very useful.

AFAIK bookworm is fine with wayland (weston, kde, ...)

I compiled mpv 0.40.0 and the commits from this PR. Results are mixed and situation is messier than before, so if you need hardware acceleration, it is better to go gstreamer or revert to debian bookworm for now.

One suggestion I can give you is to try a fresh image from https://github.com/armbian/community/releases. Make a backup of the eMMC and clean it up (multitool can do both things), then try to boot from sdcard with the new image. Newer images come with u-boot v2025.10-rc5 and a "fix" to reset the VOP before entering the kernel. Some people on the other thread reported that disabling u-boot HDMI made the HDMI work once in Linux. With kernel 6.17 this issue hit my box and I could arrange a fix, perhaps this fix will address your problem too (for reference: https://github.com/armbian/build/pull/8674/files#diff-70c2c867b6e2024080868c0d5c3230d58be2d2c4b88a24291b0469c7d2229629)

mpv official github repo. v4l2request commits are in a pull request.

I compiled mpv 0.40.0 on Debian Trixie with the patches for v4l2request, but the outcome is messy at best. There is a new hwdec v4l2request, but also two new gpu-hwdec-interop v4l2request and v4l2request-overlay. It works with acceleration when launched from a terminal, but in wayland/weston v4l2request refuses to work. I don't know what happened, but it looks like a big regression from 0.39. Better use the old mpv version IMHO.

You're welcome @Hqnicolas 👍

sorry, no idea 🤷‍♂️

@samircobra Did you try multitool? You can find it in the first post; also read carefully the first post, it contains very useful informations, for example the hint about the failing eMMC on these rk3318 boards. Probably your box has a failing eMMC. Also another important thing: we don't talk about "firmwares" here, we talk about Armbian, so if you have questions not related to Armbian, this is the wrong place.

Don't know what to tell you, it is running fine on my boxes and dmesg is clean. Also I cannot see what is your build version since the screenshot is missing the top line of the screen. 🤷‍♂️

@JaydenWithaWhy I rebuilt and uploaded again a new copy of the multittol. Please download and try again, I tested successfully on a tvbox of mine and worked fine.

"Regular" mpv coming in Debian Bookworm works perfectly fine, as Bullseye did also. There should be no need for custom mpv builds, unless some features have been removed.

@JaydenWithaWhy ok ,the source is right. The multitool should leave a dmesg log in the MULTITOOL partition of the sdcard; that log could be handy to understand what's wrong. Also you can access via SSH and run the multitool from there, so you may get some clearer output and some more details about the error. A last note, I never tested it with a 128gb sdcard; it should work but bugs are around the corner...

From my tests, ffmpeg works fine with hardware acceleration under Debian Trixie, but packaged mpv (AFAIR it is v0.4.0) does always fails hardware decoding.

@JaydenWithaWhy Multitool is supposed to resize the partition to the whole size of the media as soon as you run it for the first time on the box. About the "command not found" and black box issues, I'm not aware about. When you see the Terms, you can scroll up and down and Enter key will just proceed to the main menu. Where did you download the software?

login via ssh