jock

@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.

@Blyato that's very difficult wifi is getting working if it is yet another unkown chinese vendor chip. From the photo i can't identify it, but have never seen such silhouette

Hello, both the versions you used share exactly the same kernel, so it is unclear to me the reason only the Jammy image boots. Actually, I don't understand why you did not use the multitool to install the armbian image and doing maintenance, but however... You can actually edit /boot/armbianEnv.txt and set verbosity=7 to have more kernel logging and perhaps something will pop up. Hint: dmesg log is basic stuff to do debugging, if you can provide it, it could be very useful.

I guess the older bootloaders does not work at all with eMCP chip, if I remember correctly you need at least ddrbin v1.09 when you have an eMCP. It could be that your board came with an even newer ddrbin or something a bit customized. I guess you should ask the vendor for the original firmware and install it again to solve the issue if the command rate switching did not change anything.

Hello, AFAIK you have two options: - broken board/DDR memories - bad command rate timing The former problem cannot be solved unless you are capable of fixing the board at industrial level, but most probably your problem is the latter. Usually most boards/ddr memories work with 2T (2 clock cycles) command rate, which is more compatible because more "relaxed". For some reasons I don't know, some DDRs want 1T Command Rate. You can edit the multitool.img file with an hex editor and change the byte at position 0xABFC. You should find it to be 0x01 (2T CR), and you should turn it to 0x00 (1T CR): then write again the multitool on sdcard and try again via maskrom The multitool is also capable to switch from 1T to 2T and viceversa when the loader is installed in the eMMC, so if you burn armbian on eMMC, don't forget to use the Command Rate multitool menu option to select the right CR option!

Hello! Can't say if a step is missing, normally an sdcard with multitool on it is sufficient to let it boot from sdcard. I don't know if you have an ancient version installed without the sdcard boot or a very new installation with the missing feature in u-boot. You may take a look to this: