jock

It looks like u-boot is not able to detect the sdcard, the first part is missing because the bootloader uart speed is 1.5mbps and then u-boot switches to 115200kbps, but that's it, u-boot does not see the sdcard. The reason is unknown, and resides into the board internal wiring and it is not possible to debug that without the board at hand. It is still possible to boot from USB stick (with the multitool sdcard inserted): burn the multitool on as USB stick and put the legacy image there and the multitool on sdcard will do a trampoline to the multitool on USB stick.

Actually I forgot to update the first post: the FAT partition has now been changed to NTFS to overcome the 4GB maximum file size limitation of FAT32. I think I made a post about that, but forgot to update the first post. Sorry, I'm going to fix that right now! Despite that, the multitool works exactly the same as before.

Hello @lucat1, it is not the first time I see this board on the forums. I have never seen it, so I don't know which problem it could have, only the UART debug output could tell what is going on. Anyway, you should try to plug a male-to-male USB cable in the OTG port of the board and in your PC: if the board is in maskrom mode, you should be able to see the board from the PC using lsusb from Linux or AndroidTool from Windows. Once there, you can restore a previously made backup or erase the internal flash to force the board to boot from sdcard. If the board is not detected on your PC, try pressing the reset button behind the audio jack connector, and keeping it pressed for two seconds while giving power to the board and then try again with the male-to-male cable. Check the rk322x main thread on how to use rkflashtool/rkdeveloptool tools.

Seriously, are you thinking that thousands of log lines of the original android (I read kernel 3.10) are of any use? Paste the logs of the problematic boot, not when it goes well, damn!

Yes, of course; NAND also have a clock, shorting the clock pin has the same effect on eMMC and NAND devices. Still I haven't seen a serial log, without that, going further with support is a waste of time.

No guidance is possible without the serial logs; if people don't know what is going on, how can suggest you further steps? Next time buy an armbian properly supported SBC and you will have no troubles

We don't know! The board is new and it just does not work 🤷‍♂️ And please don't ask for solutions: proper serial logs, original device trees and firmware perhaps may help, but most we need the board in our hands to give the chance to support it.

Guidance is the first page of this thread. If you're unsure about a passage wrote there, explain with a post what you're unsure about.

@wslab wrong thread, please refer to the first page of the correct thread, everything is written in there: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/

This is the offending patch, that potentially affects all RK3399 boards

I took a look and the trip points table is provided by the mainline kernel. The trip points on mainline are: 85 °C - big cores are thermal throttled (even down to 600 Mhz from 1.8Ghz ) 95 °C - all cores are thermal throttled 100 °C - device reboots On vendor kernel instead: 70 °C - big cores are thermal throttled 85 °C - all cores are thermal throttled 115 °C - device reboots As far as I see, the mainline trip points looks for reasonable for me, and the device reboots at 100 °C which looks like a reasonable critical temperature to prevent physical damage on the long term. If you reach 100 °C and beyond, you definitely need a heatsink and proper energy dispersion. On my tests running concurrently openssl speed -multi 6 and mbw -n 1000 256 , stressing the CPU with crypto tests and DRAM for benchmarks, the board never crosses 86 °C because the thermal throttling of the big cores gets engaged and it looks sufficient to keep the soc at a reasonable temperature even after several minutes of sustained load. Of course my board is without any kind of enclosure. I don't think there is the need to really change the trip points. On your setup perhaps you don't get reboots because you're allowed to stress to soc up to 115 °C, but you should evaluate a way to remove the heat in excess rather than raise the limits, or limit the core frequency to reduce energy dissipation if you're in a constrained environment. edit: I should retreat partially: it seems that the 95°C trip point for all cores is way too high. My board hanged at 94°C during the rsa test with openssl, so quite probably it is better to change the trip points this way: 82 °C - big cores are thermal throttled 85 °C - all cores and DMC are thermal throttled 90 °C - device reboots this should also give enough room for the board to recover after reboot

Eh, I had to apply the famous libreelec patches (most of them are work from @Kwiboo, btw) that change and fix the various HDMI timings and the subsystem in general. I cut out those patches which seems to be non applicable to the case, but still there are plenty of them (I actually count 48 of them) that, in a way or another, touch the rockchip HDMI subsystem; some of them are difficult to remove because there depend from each other, but I will try to refine to get a small group of patches. Those changes seem to solve problems both with rk3399 and with rk3318/rk3328 and also provide new features, but I don't want to encounter the wall of the last time I did the refactor of the rockchip64 patches into series. BTW this is the commit on my private branch were the work is in progress (based upon 6.3, but I will rebase upon 6.4 soon)

Actually I don't remember your issue (the last post was 3 months ago), but I see @RaptorSDS was already in contact with you.

@sadp Your wifi chip is not supported by the brcmfmac driver; there is a patch for rockchip64 family but not for rk322x. I will make a Pull Request to add the patch for rk322x but have to be patient, wait a couple of weeks and it will be probably available for edge 6.4 kernel. You are on current 6.1 right now, so perhaps you may want to switch when the new kernel will be available. About the missing HDMI, it is a known problem for all R29 boards; @Hudson FAS gently offered to send me a board of such kind for me to inspect and try to fix the issue, so patience here too.

@n3o please put the log in a spoiler section

@cgutman thank you for reporting! 😉

I prepared an experimental minimal build for Orange Pi 4 LTS with some extra patches that may fix the HDMI issues: https://users.armbian.com/jock/misc/Armbian_23.08.0-trunk_Orangepi4-lts_bookworm_edge_6.3.13_minimal.img.xz Please try it and report if possible, thanks!

I resume this thread to see if anyone is still interested in this issue: I can provide a minimal testing image to see if some patches may reduce or eliminate the HDMI problem. Please answer here if there is still interest in this topic

Thanks for noticing this, and sorry for being very late on answer. I will check and fix the trip points soon; also there could be room for improvement from stock/vendor based trip points with the granularity provided by devfreq framework for GPU and DMC (read: GPU and DDR can be controlled as well to lower temperature of the board).

Sorry for the very late answer, and sorry for not shipping good news, but the last time I checked the datasheets, I also found that no I2S bus is available on the GPIO header, hence no external I2S DAC can be used directly on Orange PI 4 LTS boards

Kernel has little to do, the problem lies within the configuration of the hardware part, so it is more a dtb issue rather than kernel/software.

@ANKH yes that's true what you found, but in mainline kernel there is no such thing like custom drivers for rockchip. The problem is not the driver, but the communication with the wifi chip itself. The kernel is not able to communicate the device via SDIO bus, so it is not even able to understand the vendor and device id of the chip. Your problem is at the very hardware level, so the drivers are not yet involved in your case, and yet I don't understand if I did a mistake setting the GPIO strength values.

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.