jock

No need to recompile, rk322x already have had all the right bits in the right place for years. Everything is written down in the first page of the thread for rk332x tv boxes (What works: ---> Hardware video acceleration) in the hope people read it.

I tell you to read the first post of the thread.

rk3326 and rk3328 are not the same thing, neither is px30. Definitely no chances to run this on those SoCs; I don't know if there are images for boards using px30/rk3326 in armbian.

@GmP oook, so now I understand the differences between the two dtso files provided here and in the other thread. Do you spot other differences or peculiarities? Things that are useful are: * the gpio led (do the separate red/blue/green led blinks on both boards?) * wifi reset gpio (do wifi get detected in both boards with base configuration?) * is there a separate PMIC like rk805/rk808 on any of the boards? Things like these go into the dtso for full board support. The PMIC is very important since missing that could cause stability issues.

@GmP ok, so the leds in the previous dtso are wrongly addressed? Because in the latest dtso I see 7 leds addressed on segment 0, instead the previous dtso declares 4 sparsely addressed leds. edit: note also that your board is T98_RK3318, not T9_RK3318

@GmP thanks for the contribution, but I want to advice you that the driver changed in kernel 6.17 due to kernel developers requests and suggestion, so that device tree overlay is suitable only up to 6.16 I made a pull request to include the device tree overlays: https://github.com/armbian/build/pull/8848

@Aroldo Bossoni The optimal would be understanding the reason why the watchdog triggers, but could be a difficult task without a hint because of the closed source proprietary trust os. The easiest thing is to provide armbian images with the opensource trust os rather than the proprietary, which is totally feasible because it just requires to swap a file in the armbian build scripts. That would blow the issue away, but unfortunately the proprietary trust os provided DDR scaling and virtual poweroff. The latter is a seldom used feature, but the DDR scaling provided a dramatic improvement in performance and it is hard to give up on that. Swapping the things at runtime is not savvy: when u-boot updates, the proprietary trust os will be reinstalled overwriting whatever you put in there. I would be happy with opensource Trust OS and no runtime DDR scaling, but stil having it at a fixed decent rate (660MHz, instead of the default 330MHz), but some boards do not boot at all when they are instructed to boot at 660MHz.

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)