jock

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:

Perhaps this helps:

Because NANDs are the raw flash memory chips as-is, while sd card (as well as emmc) are both nand flash + controller. The controller provides the FTL layer and the management things. If you only have the raw NAND chip, the FTL and management has to be done in software, hence you need a kernel driver for that. There is a brief explanation in the first topic page too (NAND vs eMMC vs eMCP) if you want a sum up of the topic. edit: "fortunately" more recent low-edge chips like rk3328 and rk3528 don't have a raw NAND controller, so in the future we won't have the necessity to deal with raw NANDs

Well, sooner or later everything become "end of support", so I would not blame them actually. Probably the assembly code is necessary to avoid some kind of patent or NDA infringment against NAND manufacturers, which use different algorithms for wear leveling and so on... I want to mean that probably it is not exactly rockchip intention to use obfuscated assembly code in there, but it is more like a tradeoff due to commercial reason to let them publish the whole source code. Anyway, raw NANDs are actually a PITA from the software point of view, because you need a software FTL and all kinds of wear leveling and cells management. eMMC chips instead have their own controller that takes care of teh management and "garbage collection" of the NAND cells, so software support is much simpler.

Nope, and the answer from @Hqnicolas is right: mainline kernel has no driver for NAND controller on rk322x. To be precise, in the mainline kernel there is a driver that is capable of access the NAND raw cells, but the mainline kernel lacks a Flash Translation Layer (FTL) that is embedded as assembly code into the vendor kernel which, in turn, has a driver which does a sort of "emulation" of a block device.

The error is what you already guessed: mainline kernel don't work with NAND. You need an image with the vendor legacy 4.4 kernel if you want to install in NAND.

There should be three partitions on the sdcard, the one with the backups and images is MULTITOOL. The reason behind the three partitions is fundamentally related to the fact that the Windows is bugged and limited

On what basis you say that? Because your previous assertions about resize and GPU rendering are not exactly right: rockchip (as other vendor socs as well) can use "direct to plane" rendering, which does not use the GPU to render frames at all and resize is done by the VOP itself, not the CPU. rk3566 video decoder is rated for 4k60fps, you don't need any "turbo" because CPU also is marginally involved in hardware video decoding

@Socram Hello, it's definitely an rk322x. Despite the kernel is the same for rk322x and rk3288, the socs are profoundly different and so are the device trees. An image for rk322x would not boot on rk3288 and viceversa. Anyway, you should run rk322x-config and use the appropriate led-conf for your board. AFAIR you should have two options: led-conf8 for h20 boards with two voltage regulators (better, looking at the board photos this should fit) and led-conf7 with r29/r2b/h20 boards with single voltage regulator (worse but more compatible). You may go with led-conf8 first, see if it is stable under load. If not, go with led-conf7. Both the configs should make HDMI work