jock

@Maxxim thanks for the greetings, they are very well accepted. Perhaps you could create a new thread and put there the tutorial for better visibility

It's no secret indeed, but the armbian image has been engineered NOT to work that way on purpose because I did not wanted anything to do with existing old/buggy/limited bootloaders, miniloaders, trusts or whatever...

Armbian already offers ways to customize the final image, it is used by SBC manufacturers to build their own images, for examples. Don't understand why you should want to customize the boot process though, which is quite delicate thing. If would be nice, since you got so many of them, if you open the box and make detailed photos of the boards. And it would be even nicer to have samples of those boards that "don't boot" and those which give no video signal in my lab, since those issues are very niche cases and incredibly difficult to debug without the hardware. There are a plethora of reasons they could not boot, there are at least 4 different pieces of software chained one after another during the boot, not just the kernel. The serial adapter is essential to debug. About the missing boot, as said, it is a very delicate thing and requires good knowledge about each piece in the equation (ddrbin, trust os, miniloader/uboot SPL, uboot, the device trees, the kernel drivers, ...). You can't just swap the kernel and expect it magically works; and that's one of the reasons armbian exists: to ease the pain to boot SBCs and - as side effect - tv boxes. Sorry to stress this thing, but never worked there because you did not read carefully the first post. There's a paragraph on booting from sdcard. And did you note you could also boot from USB stick/HDD ? What are you confused about? Which pass of the step-by-step guide is not clear? They are the lowest end product available on the market, yet TX9 means nothing. Chinese manufactures give them fantasy names no matter what's inside the box, that's the reason we always talk about the boards, trying to identify them by looking at the signature and markings on the PCB.

Nope, every board and every memory chip have their flaws, so you have to take your chances. Why? Of course not. Perhaps you may need to increase the vdd_log voltage, which drives the memory controller, but don't expect great results... As you see, the board does not even arrive at booting the kernel when the wrong frequency is chosen, so the problem here is before the kernel takes control when tinkering with boot frequencies. What I have seen is that, when the memory controller driver is engaged, it is perfectly able to reach 800Mhz on board that can't even boot at 660Mhz, so something is still missing in the equation.

@ANKH Ok, the logs report that led-conf5 (no alt) is actually doing something because the device mmc4 spawns up, tries to get probed, but an error occurs. Try this other device tree overlay: I gave more strength to sdio pins, according to the original device tree. Again, the feedback with logs is useful (even if the wifi works)! rockchip-rk3318-box-led-conf5.dtbo

That's mostly because the cheapest models are usually chinese crap where costs are cut as much as possible, and you get no warranty of any kind. These are toys that at most cost 3$ of materials to manufacturers and they sell them at 25$ and, for 90% of people, they are cheap trash that sometimes work, sometimes don't.

@art3mis_17 @fabiobassa is totally right, you will need a working sd adapter because you have a NAND chip and not an eMMC chip; I just add a quick note: you must use the image with legacy kernel if you want to install to NAND. Refer to the first page for detailed instructions.

@ANKH I set up a couple of device tree overlays that you may wish to try. Try first the led-conf5 overlay, if it does not work try the led-conf5-alt overlay. Put the files in /boot/dtb/rockchip/overlay directory and then modify /boot/armbianEnv.txt to enable led-conf5/led-conf5-alt. Please post a dmesg output or, even better, the URL given by armbianmonitor -u rockchip-rk3318-box-led-conf5-alt.dtbo rockchip-rk3318-box-led-conf5.dtbo

Your goal is achieved already, since armbian already runs on those boxes, or do i miss something? Did you inspect the hardware? Did you connect a serial adapter to debug the output from the serial port? Have you read carefully and throughly the first post of this thread? Perhaps you have different boards or boards with different hardware, despite the commercial name. Multitool does not only work with old kernel version, it is made this way on purpose, to be the most compatible with the plethora of devices around; also NAND boards work only on legacy 4.4 kernel. I don't understand what you mean with "eMMC image"; there is no limitation about the storage device for armbian images (read the first post) Read the first post. Even better, this thread is filled with useful info you may need. May I ask how your university got all those cheap and trashy devices and what is the final purpose of altering their firmware? But it's okay if you don't want to share!

@ANKH According to your dtb, your board is similar to MXQ-RK3328-D4_A (led-conf3), but also has a different power-on GPIO pin for wireless, and that's probably the reason the wifi chip is not detected at all. In general, the power-on GPIO is wired to bank #1 pin 18, but on your board it is wired to GPIO bank #3 pin 8. It requires an adaptation of the device tree or a new overlay to properly support your specific board.

@Energokom good for you; by the way the operating points defined by rockchip are not the exact frequency of the ddr chips, but somehow they are just a bit below: 330 mhz, 528 mhz, 660 mhz are usually used in the device trees and that's what i replicated. I guess that's for some internal SoC synchronization reasons, but found no evidences of that. Anyway, what works for you, may not work for others, as long as the 660Mhz ddrbin has been in use for a long time in the armbian images and some people reported issues right here, so I recently reverted back to 330Mhz ddrbin for broader compatibility, although it is also a performance hit. There is another option so far, and it is the DDR Memory Controller driver, which works perfectly in the current mainline kernel, but requires the original Trust firmware that comes with rk3318 boards, which in turn, does not allow the chip to run above 1.1ghz, causing an artificial freeze. The DMC driver can switch the ddr frequency from 330 to 800mhz during runtime depending on the workload and would be perfect because does not involve the ddrbin manipulation, but the original Trust is a problem 😕

@callegar It looks like that the current kernel is still at 6.1.11 The prebuilt images will get the edge kernel, which is 6.3.x You have to switch to edge kernel, for example with armbian-config, but beware that edge is... edge! and it means that it is not as tested and might not be as stable as current

in armbian/rkbin repository

Yes, it could be the 660 Mhz ddr that is causing a bit too many troubles around. If have practice with hexadecimal editors, you can open the image find the red bytes in the top half of this screenshot and exchange with the red bytes in the lower half; save and try again.

Honestly, I don't know. I did not even know that rk322x could boot from a SPI device. About the USB thing, despite the "adapter" you may need to do what you ask, the boot options depend upon the original firmware you have on the SPI right now and, AFAIK, USB boot is not available in any original firmware. Surely the SOC itself is not capable to boot from USB, there should be a piece of software installed on the SPI (read: uboot) that will do that. If you put an sdcard in a USB dongle and then the USB dongle in the USB port clearly you're trying to boot from USB, so it won't work

Yes and no. They are known to report quite high temperatures but the heatsink is just barely warm. Surely a reported temperature of 80°C at idle is a bit too high. Mines are idling around 65°C

Nope, usually the ethernet is working very well by default and does not require any specific configuration: both phy and mac are in the 322x SoC, so once configured properly in the dtb, there are practically no chances of misconfiguration at kernel level. There may be some corner cases, but as long as this thread exists, I never encountered a board which required a specific configuration for ethernet.

You should use the images from this thread instead of the firefly

I'm afraid you have to find and use the emmc clock pin to enter in maskrom mode and clean the emmc with rkdeveloptool using a male-to-male cable

This is essential, since nand is supported only with legacy 4.4 kernel. That's clearly and boldly stated in the first page. That board is perfectly supported, but probably it is more convenient for you to run a fresh mainline kernel from sd card than an ancient legacy kernel from nand.

Sorry, just to be clear (I'm curious...): you tried the latest Ubuntu Lunar with edge 6.3 kernel you can download from https://github.com/armbian/community ?

@mydeardiary hello, as @RaptorSDS said, rtl8723as and rtl8723bs are two different chips and require different drivers and firmwares. rtl8723as driver is not in the linux kernel and looks like quite difficult to find a suitable driver. Libreelec folks did some adaptation for the rtl8723au: https://github.com/dtechsrv/LibreELEC-AML/pull/24

I would suggest you to keep the multitool around. Make a backup first of the entire system, but beware the 4G file size limit. You have to double check the validity of the compressed file after you make the backup, because the multitool won't give you errors 😕 You can use it in case something happens and you need to do maintenance. About the upgrade process per-se, I did a couple of times an upgrade from buster to bullseye and a "downgrade" from sid to bookworm. Despite the "usual" issues when doing upgrades, kernel and bootloaders have been kept at their places. Anyway check that the kernel, uInitrd and dtb files are still there in /boot after the upgrade (they should) and follow the standard debian/armbian upgrade instructions and cross the fingers!

@EmilB I'm getting quite confused among the "unmodified" and "original" attributes. Still I don't understand if you have had success in installa jumpstart on nand or not. One thing is sure: the bootloader of multitool and armbian is well able to boot from USB, so if you keep the sdcard in the slot, it will also try to boot from USB. As you see, there are several stages in the boot process that can lead to a multitude of situations, it's not easy to explain and understand the "tree" of options that will come out. One thing that is often sure is that if you completely erase the internal NAND/eMMC, the board will indeed boot from sdcard, but with NANDs if could be not so easy to completely erase the flash due to differences among the already installed bootloaders (ie: it may work from multitool, or may require rkdeveloptool, ...)

@EmilB sure you can mix things. On the first kernel upgrade the whole thing will break and the system won't boot anymore. I won't suggest to others doing the same.