jock

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.

Yes, it is

@Alex ThreeD I did not delve into ethernet, but the "No ethernet found" message I often see in u-boot makes me think it has some troubles. Also I did not further investigate because v2024.01 finally happened to be transitioning version, in fact I already have a branch working with v2024.07-rc4 as suggested by @Kwiboo in the github issue about memory addresses and relocation. In particular, there is the rmii support patch that is being carried on starting from v2022.04 or even earlier and still applies, but don't know if it works correctly. It is important to note that this patch - as you may see - changes the device tree node substantially and that could be the reason mainline code breaks.

First page: The Multitool does not boot

Perhaps you don't have an MMC but a NAND, so installing recent armbian won't work. You should post the dmesg log here, the multitool saves a copy on the partition of the sdcard after the first boot

Can't really get a clue about the issue. I mean, in the mainline kernel cma_alloc seems to be used in a non-core driver, altough it is very seldom used: https://elixir.bootlin.com/linux/latest/A/ident/cma_alloc so I guess that's not something client drivers should use. Going back to rockchip 5.10 vendor kernel source code laying on my notebook I see: paolo@armbian-build:~/rk3528/linux-rockchip/mm$ rgrep -IH 'cma_' | grep EXPORT cma.c:EXPORT_SYMBOL_GPL(cma_get_name); cma.c:EXPORT_SYMBOL_GPL(cma_alloc); cma.c:EXPORT_SYMBOL_GPL(cma_release); cma.c:EXPORT_SYMBOL_GPL(cma_used_pages); cma.c:EXPORT_SYMBOL_GPL(cma_for_each_area); But those EXPORTs are not present in the mainline 5.10 kernel... This old LWN article perhaps explain the rationale: and things like dma_alloc_coherent() should be called instead: there are hundreds of references to that, and it's far easier call too. Perhaps the driver should be fixed to use the proper API, as exporting those symbols actually seems a violation to me. I don't have a rational opinion on including those small patches in the armbian vendor kernel; vendor kernel often host many of those shortcuts; unfortunately shortcuts are one of the reasons they are also hard to maintain. The ideal would fix the driver. edit: it puzzles me that the kernel linked by @Tony3 does not contain those EXPORTs either: https://github.com/tbsdtv/linux_media/blob/latest/mm/cma.c

Let's run the wheel and bump to v2024.04 ? Every u-boot bump is a lottery ticket 😑

The hint was right, but you did not read carefully. See the paragraph "The Multitool does not boot / How to burn image directly on eMMC"

Hello, the patch is shared for all rockchip 64 bit devices, since the problem was shared with several rk3399 boards. You should first start with the output of these commands to see if the system gets the monitor EDID parameters: sudo i2cdetect -l sudo get-edid | parse-edid then perhaps see if you have success in changing HDMI cable, or try with a different monitor. The patch was merge here and changed some timings. When timings are changed, some configurations gets benefits but some others may regress.

@Alex ThreeD actually it is in the wild and it looks to work right to me, also executes boot.scr script. boot.scr is essential to read armbianEnv.txt and apply dtb overlays as well. Did you notice something wrong?

@Blyato From dmesg I see the wifi chip is just turned off: [ 1.716294] mmc1: Failed to initialize a non-removable card I'm pretty confident that the issue is related to the GPIO power pin of the wifi chip being incorrectly set. You mentioned you are using led-conf7, which is the right device tree for R29 boards, but it seems that your board is a different version/revision and requires some adjustment. To do such adjustment, I definitely need the device tree or the backup of the stock android. A possibility is to try other led-conf options and see if the wifi chip is at least recognized, but I don't suggest to do so because led-conf7 is vital for the stability of the R29 boards: without it, your board will probably be unable to boot at all.

Yes, but there are several bcm433x variants. You have to post dmesg log.