jock

@pakos96 apparently, the kernel bug has been fixed and it should work

@hfrts hello! First of all: no documentation from the manufacturs of any kind. Cheap tv boxes come without any kind of documentation: they are dirty cheap hardware with barely working software. The board footprint/silkscreen is indeed the first thing to look for to find the matching led-config: all known boards are listed within the rk322x-config script. If your board is not listed, then the stock firmware (or its device tree) and photos of the board most of the time are enough to properly match an existing led-config with the board or create a new led-config for a new board.

@bellad unsupported chip, there is nothing to do 🤷‍♂️

@wilsonh hmmm, that commit I think it was an attempt to bring the libreelec patches into rockchip64 family. Those attempts generated a lot of discussions, where many were happy and some concerned. Concerns won the battle, and the branch was never merge into mainline, despite it was tested a lot by libreelec folks and gave an all-around improvement in the video/display front. The patch in the main armbian branch instead is a knitwork I did around the libreelec patches to figure out what could fix the HDMI issues on rockchip64 in the latest kernels without including the whole libreelec patchset. Unfortunately (or fortunately) I have no issues with any monitor/TV I have here around, so I could not test directly the outcome of the knitwork. I got some positive feedback from the community, so the smaller patch went in main armbian, but some useful things that fixed issues may have been left out in the process. Anyway I read that, with kernel 6.12, a number of patches that are in the kernel mailing lists (that also are in the libreelec patchset) will be finally mainlined. Hopefully, that would be a step forware the right direction (or wreck everything...)

@wilsonh hello! There are no particular compilation steps, once you put the patch in the right place (patch/kernel/archive/rockchip64-6.6), the armbian build system should automatically apply it. Anyway, the patch is already in the main branch of armbian for quite a lot of time; perhaps the patch does not solve the issue with your monitor - for example, I have been unable to run my AOC 3440x1440 monitor on any SBC I have here around, Opi4 included 😕

Which ram speeds? are you aware that ddr scaling does not work on these tv boxes?

That will take some time to set the whole setup; unfortunately it is not easy task to bring up a system which could be used easily to rebuild the packages, but will do in the future. Can't say when though.

@raven123 yes, I moved rockchip64 edge kernel to 6.10 and brought in the patch to fix the gpio2 bank that was causing the whole eMMC issue. BTW, packages should be available in the near future when the armbian server will rebuild the things (hopefully, next sunday)

No, because it is old and buggy. It would perhaps let some boards work but it will break many others. The best option is to use the opensource trust os, but it lacks some features (DDR frequency scaling, virtual poweroff most of all).

@Netraam31 First fact: the problem is in a mainline upstream kernel driver; there is no device tree magic sauce that will fix until the driver is fixed. The patch to fix the issue is already around in the kernel mailing lists (https://patchwork.kernel.org/project/linux-rockchip/patch/20240709105428.1176375-1-i@eh5.me/), if it will take more than another week to be merge, I will import into armbian patches set. Second fact: the big fat disclaimer when you run community armbian images tells you that they are not stated to run in production. If you do so, you have no guarantees of any kind. Community supported boards (CSC, as all tvboxes are), can only have community images. Supported boards (proper SBCs) have supported images.

@Mikee Mike the difference is that the "old tee" is a very old TrustOS proprietary and closed source binary from rockchip that does not put the board in standby after one minute. On the other side it has several compatibility issues among various boards. The "regular" multitool has a newer TrustOS that works fine for the majority of the boards around, but on some very rare boards will put them in standby after one minute. As long as they are closed source binaries, we don't know why that happens.

Suggesting a tv box is the best way to waste money in something probably unsupported.

This definitely requires more attention. Each uboot revision seem to change something and every time is a lucky shot.

About the eMMC issue, this is the patch series that breaks eMMC and also GPIO pins (leds does not work either): https://patchwork.kernel.org/project/linux-rockchip/cover/20240606125755.53778-1-i@eh5.me/ It has been mainlined in kernel 6.6.37 and probably will break more rk3328 boards as well. Reverting the patch series from the 6.6.37 kernel, it works again

ADVICE @tERBO discovered, at his expense, that upgrading the kernel to v6.6.38 breaks the eMMC support (see his thread), so please do not upgrade the kernel until the issue is solved! The issue seems related to some patches that have been mainlined in the kernel, but further inspection is needed to be sure what is causing the problem.

@tERBO Here it is, kernel 6.6.38 and emmc broke on my system too: I will try to revert some patches mainlined patches in the next days to see if it fixes something. The rk3308 should be quite different than rk3318/rk3328 and the commit was limited to rk3308-rock-pi-s, so I don't think that's the issue.

@tERBO ok thanks, that's an useful information! So it is not uboot but the kernel itself that breaks something. I checked the armbian commits in the rockchip64-6.6 patch archive and nothing relevant changed lately, but I see from the dmesg you posted that the working kernel is 6.6.36, instead the broken one is 6.6.38 There are some changes in the mmc subsystem for kernel 6.6.37, I wonder if something there may have broken the thing https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.37

Uhm... I'm just wondering and looking at the dmesg provided by @tERBO: the kernel is the same 6.6.36; maybe it is related to uboot - recently it has been upgraded to v2024.07 from previous v2024.01 - that is doing something with the eMMC (mmc2 in dmesg) and leaves the chip in a bad state. the sdcard (mmc0) and sdio (mmc1) instead are pretty fine and does not seem to suffer any issue. I need some time to guess that out :/

there's a mmc_select_hs200 failed, error -110 line in the dmesg log. You have to remove rk3318-box-emmc-hs200 overlay from the armbianEnv.txt, that is probably causing the problem.

Well, that's curious at best, dmesg surely will tell about the mmc controllers and why they are gone. For sure they are not loaded as kernel modules but indeed they are built-in the kernel, so they should still be there. I will try with a build from trunk 314 as you suggested and then upgrade to see what happens of my board, but I'm puzzled because the kernel is always version 6.6.36. You may want to try removing the device tree overlays from /boot/armbianEnv.txt, perhaps something is off with them

Does not help. Anyway I just did the upgrade on a system of mine and it rebooted fine. Same kernel. You may try to boot armbian from sdcard to debug the issue or wait for some time until the initramfs shell appears. Consider that these tvboxes have defective emmc chips which may break easily, if the upgrade was consistent it may have failed.

Hmmm, so after a simple apt update && apt upgrade the system does not boot anymore? Is your system installed in emmc or sdcard? Could you please tell what board you have and the content of /boot/armbianEnv.txt?

Sorry, forgot to mention that you have to plug the male-to-male cable in the OTG port; other ports won't work. That's the maskrom mode. Anyway you can try to boot armbian from sdcard

@GSAR Hello, you can turn the box on while you keep the reset button pushed for 15/20 seconds. Once there, you can use the a male-to-male USB cable to connect the box to a PC and use rkdeveloptool to erase the internal flash and restart. Otherwise you can follow the easy way and burn armbian on the sdcard, run it from there and erase the internal flash to do the job again via multitool. You may also run armbian-install to install to emmc directly from the running system on sdcard

I don't remember if there's a device tree overlay to switch the USB2 and USB3 OTG ports to device mode, but you can alter the device tree and change dr_mode="peripheral" for the controller you want. USB3 controller appears to be more reliable than USB2 in device mode.