jock
-
Posts
1846 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
45 minutes ago, n3o said:
here I have posted serial log https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=169159
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!
-
4 hours ago, RaptorSDS said:
@jock is there a maskrom mode for NAND ?
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.
-
9 hours ago, calusbr said:
Any guidance or insights on how to overcome this issue and successfully boot from the SDCARD would be highly appreciated.
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
-
23 minutes ago, Benedito Portela said:
what can be this problem?
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.
-
15 hours ago, calusbr said:
I've attached images of the board and the boot screen for reference. Could anyone provide guidance on how to successfully install Armbian on this device or recommend any tutorials for initializing the SD card? Your insights would be greatly appreciated.
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/
-
-
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
-
1 hour ago, going said:
Please describe briefly the problem that you managed to solve in order to make HDMI work
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)
-
5 hours ago, n3o said:
done... what can You tell me about the issue?
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.
-
-
-
I prepared an experimental minimal build for Orange Pi 4 LTS with some extra patches that may fix the HDMI issues:
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
-
-
@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.
-
3 hours ago, LFPoulain said:
It works ! But I have green lines jumping on the screen sometimes
. But it's ok for configuring 
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.
3 hours ago, LFPoulain said:Why is it 6.3 kernel instead of 6.4.7 ? And also 23.08 instead of 23.5 ?
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.
-
11 hours ago, LFPoulain said:
Where could I find it ? Is it a specific branch ?
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.
11 hours ago, LFPoulain said:I have another question in mind, and I am greatly interested in the answer. I use Armbian because the power of these boxes is sufficient, their price is very reasonable, and also because the original Android firmware is riddled with malicious code. I am having a bit of trouble understanding the bootloader that allows the Multitool to start. Is it native to the CPU, or can it be modified by the box manufacturer ? I read that the Armbian image comes with U-Boot. Does this completely replace the original one? And most importantly, can there be malicious code at this level ? Thank you
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.
-
54 minutes ago, LFPoulain said:
So the board is booting right ? Is there anyway to apply SSH on boot ? I don't need HDMI as I'd like to use the board with docker and portainer
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
54 minutes ago, LFPoulain said:I'm ok to send you one of the 2 boards to try yourself ! That's seem fair to me with all the work you've done so far
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.
-
3 hours ago, LFPoulain said:
Do you have any idea why this might be happening?
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.
H20 Box with RK3228A bricked
in Rockchip CPU Boxes
Posted
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.