jock

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.

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