jock

When you have 4 cores, you can achieve 400% cpu usage; top reports it that way.

You would try an Ubuntu distro and enable the oibaf repository to get cutting edge mesa. Default mesa from debian and ubuntu is a bit older and does not contain specific fixes for mali-400/450 Oibaf repository is already set in /etc/apt/sources.list.d but the line is commented by default. Removing the comment and then running apt update && apt upgrade should do the trick. Also note that in X11 you may want to enable the vsync when possible, which turns out to perform much much better because with vsync on the driver will use page flipping, with vsync off will use buffer copy that reduces performances a lot.

Not the best choice, if you accept my opinion. Much better to use a proper SBC for those kind of tasks, perhaps something with rk3328 and a decent amount of eMMC, since HA is going to write its data series. On this particular board I don't even know if wifi is going to work, since it got a rk915a chip which currently is unknown.

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.