jock

Ok but you should provide some additional info about the display you are using; it could be an HDMI issue (timings, cables, especially with 2K/4K displays) or a box memory issue (unlikely). I made some cut work against the original libreelec patches, and I really hope that it is not the cause of the issue. Because the armbian patches have not yet been adapted to 6.4.x; everytime there is a new kernel it is not trivial to fix all the patches to make all the boards and all the wifi chips work, actually it is quite painful and time consuming task, especially for rockchip64 family which covers a huge amount of boards. Also the armbian version is 23.08 because it is the next august release; the current release is 23.05 (not 23.5)

Here it is the experimental minimal image based upon kernel 6.3 with some video patches: https://users.armbian.com/jock/rk3318/Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz I did not test it at all, but should be sufficient to put it on a sdcard and boot with the sdcard inserted.

Yes, there is the old branch on my fork: https://github.com/paolosabatino/armbian-build/tree/rockchip64-patch-series , but your mileage may vary, I don't update it anymore. There are various stages chained together to boot the boards. The armbian bootloader completely replaces the board bootloader, the only rockchip proprietary thing is the DDR memory initialization, which is the very first step. All the further steps (U-boot SPL, Trust OS, U-boot and finally the kernel) are binaries compiled from opensource code by armbian scripts during image building. In the android original image, instead, malicious code can be injected in any of the steps; the Trust OS is the most dangerous piece of code, because it runs with highest security level in a piece of memory even the kernel does not have access to. Whatever code is inside the Trust OS binary, you can't know anything about of what it does. On armbian images, both Trust OS and U-boot are compiled from the mainline open source code available on github.

You should try to access via ssh if you have a way to discover the IP address. Some cases that have been discusses in the past, the board was reactive, just HDMI was not working right Actually I have to correct myself: I think that the real problem is related to the HDMI timings of the HDMI device and not exactly to the board itself. I don't know if this is exactly your case, but in the past reports people reported that the experimental image based upon a 5.19 kernel with the libreelec patches was working, where other kernels where not working at all. Perhaps I could give a look into this weekend, and propose a minimal image with some tailored patches to see if they address the issue. This could be useful for other people with Orange Pi 4 LTS board (rk3399) that have lamented the same HDMI issues.

Yes, it seems that recent kernels have some kind of HDMI issue that makes them not displaying anything. Unfortunately my rk33x8 boards are both working fine with current and edge kernels, so I can't replicate the issue and can't fix it. Some people reported that there are patches from libreelec project that fix the problem, but as long as I can't try it myself, I can't selectively incorporate them into armbian. I tried in the past to import the whole libreelec patches, which include many fixes and better support, and also did a lot of patch rebasing work, but some maintainers where not happy, so I gave up.

@Zacky Travis as already said, no, it is not possible. Also your board may not be able to boot from sdcard at all. Please refer to the support thread about that.

This is the support thread for these things: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/ As you already noticed, the board is very new and we've never had any chance to deal with that directly, so it happens that the board does not boot. However, I will never stress enough the fact that, for reliability and compatibility, it is much better to buy an officially supported SBC: https://www.armbian.com/download/?device_support=Supported

@ANKH I think there are no other things to try, so either we want or we don't, it's a dead end.

@ANKH This is the last thing that can be changed, so try this other one and let's hope 🤞 rockchip-rk3318-box-led-conf5.dtbo

No, I won't, and I don't suggest doing that: it will make device tree overlays unusable and will break the installation on next kernel/bootloader update.

@fangis I don't know why your driver is looking for firmware in /etc/firmware; perhaps you're running on legacy kernel 4.4? Maybe you can put the firmware file there

Here come another, I hope this is the last one 🤞 rockchip-rk3318-box-led-conf5.dtbo

@fangis It is not a good idea to cut the stack trace in the middle when you want to do debug. Also put the log in a "spoiler" section to make easier to read the thread. @mattmar I don't understand the part about the usb adapter: if are you using it to program the sdcard on the PC then it does not matter. If you're using it on the box, then it won't work. Also I don't understand what does not boot: the multitool or the armbian image? AIDA is not useful, as usual we need the serial output and photos of the board.

Then use 533 Mhz! 🤷‍♂️ Of course it does not work, as I already said, images don't use the rockchip miniloader but u-boot spl. I know nothing about those "other images" you talk about And no, the ddrbin is v1.16; I don't even know there is a v1.19 around

Of course I don't know, perhaps a bad power supply? Perhaps your router/switch is faulty and it is feeding a current back to the board? I can't answer such question. miniloader has nothing to do with ddr frequency and armbian images are not using the miniloader at all. They use u-boot SPL for that boot stage. About the 666 mhz ddr, I already explained it to you few posts ago. Who knows? Look, I am not the Oracle of Delphi that has answers to all questions; if you have the doubt, you have to find a way to check it yourself! After all of this, you did not post not yet any serial log output from the board. I don't have a crystal ball to tell you what's happening on your board 🤷‍♂️

@ANKH Ahhh I see a made a mistake in the last dtbo I sent you. Please try this other one: rockchip-rk3318-box-led-conf5.dtbo

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