CSC Armbian for RK322x TV box boards

[xwiggen]

3 hours ago, jock said:

Urgh, that's bad dmesg should tell us something more, if you can upload it here it will be surely useful!

 

Did you have your rootfs on eMMC or sdcard? I'd rather check on my boxes for the same behaviour, looks like something is missing/messing with device trees and mass storage device disappears.

 

TBH, I never tried to upgrade from legacy to mainline via apt-get recently, so I hope there isn't a hole there. Stay tuned, I'll check ASAP.

 

edit: don't you have NAND mass storage, do you? If so everything explains easily since NAND is not supported on mainline because there is no driver

 

Edited October 16, 2020 by xwiggen
added dmesg

[fabiobassa]

@xwiggen

is strange situation this !!!

Please could you be so kind to boot with multitool and again check lsblk ?!

Mostly 329q 4k I have seen with DDR3 had NAND .
This is a unusual case and yes, it clearly says that emmc was not initialized
mmc2 error while etc etc etc .....

Only a 3rd tool such as multitool can help to clear the situation

[jock]

@xwiggen

Uhm, I inspected the device tree of the mainline kernel and the only thing that could be interfering is this line:

rockchip,default-sample-phase = < 0xb4 >;

I made a device tree without that line, you can try to install the mainline kernel and substitute /boot/dtb/rk322x-box.dtb with the one I propose you here.

Use it for recent mainline kernels only!

 

If your box works, I will remove that line in the generic setup (which is also useless there BTW, because it should be important only when DDR mode is in use).

rk322x-box.dtb

[xwiggen]

17 hours ago, jock said:

@xwiggen

 

 

If your box works, I will remove that line in the generic setup (which is also useless there BTW, because it should be important only when DDR mode is in use).

rk322x-box.dtb 39.87 kB · 2 downloads

I flashed a 4.4 buster image to emmc, replaced the rk322x-box.dtb inside linux-dtb-current, removed linux-dtb-legacy/linux-image-legacy, installed linux-dtb-current/linux-image-current,

and ...

It works! Thanks very much. Will do some testing with GBM/GLES now

 

edit: in 5.18 I see a mtd raw rockchip controller available? (not for me)

[xwiggen]

update;  to get the system reasonably stable I've been forced to use active cooling, high load with 70+C temps make the board hang.

This is pretty obnoxious as this temp is reached easily (fanless) in idle state even when limiting cpu frequency, so my intention of running even simple emulation is a no-go.

 

[jock]

51 minutes ago, xwiggen said:

update;  to get the system reasonably stable I've been forced to use active cooling, high load with 70+C temps make the board hang.

This is pretty obnoxious as this temp is reached easily (fanless) in idle state even when limiting cpu frequency, so my intention of running even simple emulation is a no-go.

 

Do this happens only with mainline kernel or also with legacy kernel?

I have no real problems running boxes at 70°C, actually I have one which is happily running at 89°C with libreelec, then happens the thermal throttling which keeps frequencies low.

As often pointed out also by @fabiobassa, the temperature seems to be erratic because the heatsink is usually just a bit warm while the software reports temperatures that may cause you a burn.

From what I learned as an overclocking/downvolting fan in the past, the temperature heavily depends upon the processor production process and usually there is an "offset" you should take in consideration. Maybe the datasheets can make things a little clearer, but considering also that these SoCs are almost "ghosts" and they really look like production scraps I don't think I will find anything valuable there.

[xwiggen]

26 minutes ago, jock said:

Do this happens only with mainline kernel or also with legacy kernel?

 

Mainline only. Legacy runs stable at 73-81C, apart from GLES/GBM/FBDEV issues with mali blobs.

Must say I've experienced some lockups with WiFi on H3 also with 5.8.x this week (RTL8189FS), one kernel panic on zeropi H3

[usual user]

5 hours ago, jock said:

the temperature seems to be erratic because the heatsink is usually just a bit warm while the software reports temperatures that may cause you a burn.

Don't confuse the junction temperature with the ambient temperature of the heatsink, as that is the one the CPU temperature sensor is reporting. How long it takes to propergate to the surface depends on the thermal resistance and can take quite some time.

5 hours ago, jock said:

I have no real problems running boxes at 70°C, actually I have one which is happily running at 89°C with libreelec, then happens the thermal throttling which keeps frequencies low.

If I read the previous attached dtb correctly, then the thermal system kicks in at 105°C. Relying on load dependent DVFS does not take any account in thermal constraints. How the thermal system really works can be deduced from a tmon log created during a stress test.

[jock]

42 minutes ago, usual user said:

Don't confuse the junction temperature with the ambient temperature of the heatsink, as that is the one the CPU temperature sensor is reporting. How long it takes to propergate to the surface depends on the thermal resistance and can take quite some time.

I'm aware of the great difference between the two, nonetheless a reported temperature of 70-80°C, if thermal pad/paste is correctly applied and effectively transferring heat, I expect the heatsink to be quite warm, not just mildly warm as usually happens with these chips.

Years ago I made a tweak utility for AMD chips for linux and had to read some chapter of the datasheet througly. The reported temperature was taken using a thermistor diode in an arbitrary scale with an arbitrary offset. What worked in way for 90nm chips was not working the same way with 65nm chips and temperature offsets were completely different.

 

I'm guessing (I have no certainty) that our rk322x - like any other - have the same arbitrary scale and offset, so I'm a bit skeptic about reported temperatures. My guesswork is purely empiric, I'm no electrical engineer so I don't know all the variables that make up the game.

42 minutes ago, usual user said:

If I read the previous attached dtb correctly, then the thermal system kicks in at 105°C. Relying on load dependent DVFS does not take any account in thermal constraints. How the thermal system really works can be deduced from a tmon log created during a stress test.

Uhm, on my libreelec box I see the first trip point at 90°C and critical at 115°C.

Could you please clarify the second sentence?

 

[usual user]

1 hour ago, jock said:

Uhm, on my libreelec box I see the first trip point at 90°C and critical at 115°C.

I have only looked at the attached dtb and there only the 105°C trip point is bound to a cooling device. But without a tmon log I can't tell how often this is fireing.

 

1 hour ago, jock said:

Could you please clarify the second sentence?

Fequency scaling is controlled by CPU load via governor or user settings. It does not obey any thermal restrictions. Cooling devices obey thermal restrictions and control the scaling.

[xwiggen]

On 10/19/2020 at 2:07 PM, jock said:

 Maybe the datasheets can make things a little clearer, but considering also that these SoCs are almost "ghosts" and they really look like production scraps I don't think I will find anything valuable there.

Don't think so either,  considering reports about high load freezing on rk3288/rk3328 I suspect there's also some design issue wrt interrupt handling.

[the_collector]

On 10/11/2020 at 12:03 PM, jock said:

Glad you went a step further.

This looks definitely a new board I never dealt with.

 

The multitool sources are available on my repository https://github.com/paolosabatino/multitool

However if you can boot the multitool from the USB stick you can get a shell and look into dmesg for further details, like for example if the emmc and sdcard are seen by the kernel, it's a starting point to understand why u-boot does not detect the sdcard.

 

You should also be able to interrupt the u-boot bootstrap and use it's interactive shell to get further info about the mmc subsystem. Commands like mmc info and mmc list should be useful to start with. U-boot shell has its own shell commands, but you should be easily find them somewhere on the net.

 

 

I finally got around to playing with this again and spent a few hours. The upshot is the kernel in multitool can recognise the SD card perfectly fine, however the u-boot image does not. When I previously had the multitool booting with the USB workaround the kernel was running from the SD card, u-boot was being launched from the SD card but u-boot itself can not see the SD card, by having the USB stick in the OTG port u-boot can then read that and read extlinux.conf to proceed booting multitool from the SD card.

 

Eventually after looking through the multitool source (thank you for linking!) I figured out if I flash the SD card with the generated legacy-uboot.img it all boots and works perfectly.

 

If getting this running on mainline u-boot is something anyone cares about I'm happy to dig in and help out but hand-holding would be required unfortunately as embedded systems are a new thing for me at the moment.

[jock]

On 10/19/2020 at 10:30 PM, usual user said:

On 10/19/2020 at 8:33 PM, jock said:

 

I have only looked at the attached dtb and there only the 105°C trip point is bound to a cooling device. But without a tmon log I can't tell how often this is fireing.

armbianmonitor -m should be useful for that task, by the way it reports also the "Cooling State" and from what I intend, the maximum operating frequency is modulated around cooling states. I will try to post a log here as soon as I can

 

17 hours ago, xwiggen said:

Don't think so either,  considering reports about high load freezing on rk3288/rk3328 I suspect there's also some design issue wrt interrupt handling.

To be honest, I never experienced freezing neither on rk3288 nor on rk322x. the rk3288 tvbox I have has the first trip point at 80°C and I used it often to compile, even kernels sometimes, and it never failed.

rk322x have skyrocketing temperatures, but as said heatsinks are just a bit warm. I never stressed them too much, but don't remember of sudden lockups recently that could be caused by overheating.

 

 

[jock]

7 hours ago, the_collector said:

I finally got around to playing with this again and spent a few hours. The upshot is the kernel in multitool can recognise the SD card perfectly fine, however the u-boot image does not. When I previously had the multitool booting with the USB workaround the kernel was running from the SD card, u-boot was being launched from the SD card but u-boot itself can not see the SD card, by having the USB stick in the OTG port u-boot can then read that and read extlinux.conf to proceed booting multitool from the SD card.

 

Eventually after looking through the multitool source (thank you for linking!) I figured out if I flash the SD card with the generated legacy-uboot.img it all boots and works perfectly.

 

If getting this running on mainline u-boot is something anyone cares about I'm happy to dig in and help out but hand-holding would be required unfortunately as embedded systems are a new thing for me at the moment.

Probably it is not due to u-boot itself (legacy vs mainline) but the device tree used which may be different.

Sometimes minimal differences that are tolerated by the majority of boards are not well tolerated for some of them. That's exactly the issue @xwiggen had with the eMMC just above.

Unfortunately once u-boot is compiled, the device tree cannot be inspected easily because it is hardwired in the binary. Maybe binwalk can extract it, but I'm not so sure. I need to check the sources though.

 

If you wish to dig in is always very well appreciated, but it may be frustrating if you're new to device trees/embedded world, expecially if the problem is a needle in the haystack

[usual user]

2 hours ago, jock said:

armbianmonitor -m should be useful for that task

I doubt it collect enought fine grained data for a good interpretation.
Here is a tmon log visualisation of a glmark2-es2 run:

Spoiler

Look at the temperature differences between CPU and GPU, despite the small distance.

[balbes150]

@jockThe TV boxes section is closed for users to add information, so your topics have been moved. If necessary, specify a place on the forum where it is better to move your topics.

[jock]

Thanks @balbes150 for moving the thread!

[tediwildan]

Thanks [mention=1215]balbes150[/mention] for moving the thread!

Where should I go for further information?

Sent from my SM-C9000 using Tapatalk

[jaum20]

Any chance of getting this patch on the legacy kernel?

[Alex83]

I would also love to know where we continue our very constructive discussions? I think the project shouldn't die because of a closing thread... 

 

 

[fabiobassa]

As far I can see and undestand the 3ad is MOVED not closed ,as is easyly seen that we continue to post here.
continue our discussion here, thanks

 

[jock]

17 hours ago, jaum20 said:

Any chance of getting this patch on the legacy kernel?

I may give a try this weekend. With a grain of luck it applies without hassle.

[jaum20]

On 10/28/2020 at 5:51 PM, jock said:

I may give a try this weekend. With a grain of luck it applies without hassle.

 

Thank you for answer. I tried and looks like that the legacy kernel (4.4) is too old for this patch. I have changed it and now the patch is applied but my device still not being detected. 

[jock]

On 10/30/2020 at 9:21 PM, jaum20 said:

 

Thank you for answer. I tried and looks like that the legacy kernel (4.4) is too old for this patch. I have changed it and now the patch is applied but my device still not being detected. 

If you followed the instructions, the patch applies and you still don't get the device recognized you should first start getting the VID/PID of the device and see if it fits into the list covered by the patch. Also be sure to install the kernel correctly (both the kernel image and the modules). I'm not very into bluetooth so can't help with the command line tools to get the info you need, but I quite sure you can find something around for that.

[Alex83]

Hey guys, 

 

I stock with my device again. The wifi doesn't work as it seems and so I have no network connection anymore. If I connect it to the TV and plug a keyboard in I see there are pronlems with 

 

 

Failed to start Raise network interfaces. 

 

 

If I login and see the armbian-config I can still discover all networks around. When I try to connect it shows the error message 

 

 

Connection... 

 

Could not activate connection: Activation failed: The Wi-Fi network could not be found 

 

 

 

So unfortunately I can't copy now dmesg or log files without the network interface. 

 

Any suggestions how to activate the wifi again? 

 

 

I use armbian 20.08.7 with legacy kernel 4.4.194-rk322x

 

Update: I completely deleted the content of /etc/network/interfaces and all wifi access point information im armbian-config menu. 

 

After a reboot and try to book into my access point it worked.... Strange... 

 

I upgraded everything, but still no reboot possible with NAND installation. 

 

Also I noticed during an new Iperf3-test with the line

 

 

Iperf3 -c localhost 

 

 

during the test watching htop from another machine that only 2 of the 4 cores are raising to 100% and the other 2 are around 5-8%, so I guess the multicore using doesn't work so well like on other devices at the moment... 

 

Maximum measurements are again ~640 Mbit/s. 

[jock]

17 hours ago, Alex83 said:

Update: I completely deleted the content of /etc/network/interfaces and all wifi access point information im armbian-config menu. 

 

After a reboot and try to book into my access point it worked.... Strange... 

Software issue then, don't know what may have happened, it depends a lot on your usage.

 

17 hours ago, Alex83 said:

I upgraded everything, but still no reboot possible with NAND installation.

No changes in that sense

 

17 hours ago, Alex83 said:

during the test watching htop from another machine that only 2 of the 4 cores are raising to 100% and the other 2 are around 5-8%, so I guess the multicore using doesn't work so well like on other devices at the moment... 

Multicore works fine, iperf is not a proper test. Use openssl speed -multi 4 rsa if you want to see all the cores in use.

[jaum20]

I think I messed up my system.

 

I'm using the latest ubuntu minimal legacy image, only to use retroarch. I installed the media packages linked on the first post and everything was working fine untill today. I tryed to move some files from an lakka image to  /usr/lib/arm-linux-gnueabihf/ and now when starting retroarch I get the error:

 

 

retroarch: error while loading shared libraries: libgbm.so.1: cannot open shared object file: No such file or directory

 

Already tried to reinstall the media packaeges, reinstall libgbm1 via apt-get, but the problem persists. Any way to fix this without a complete clean install?

 

thank you

 

EDIT: already solved manually reinstalling the libmali packages. Not sure why rerun the install_media script don't solved this

[Yeoj Henrie Sayadi]

On 7/17/2020 at 3:35 AM, jock said:

Hello,

memory performance is a bit problematic. The frequency is fixed at boot time to 300 Mhz for DDR2 and 600 Mhz for DDR3 boxes. There are three main reasons:

1.  there is a constraint against an internal clock running at 1200 Mhz and RAM must be an integer divisor of that frequency (1200/300 = 4, 1200/400 = 3)
2. the kernel memory controller driver, that does the memory reclocking up to 800 Mhz, needs the proprietary rockchip trust os to work, but since I use an open source trust os (OPTEE) here, it will never work
3. DRAM chips among boards are different and may have different access timings, so something that works for a box may not work for another one, even if it is configured at the very same frequency. Sometimes the boards are so cheap the manufacturer installs faulty memory banks that are not even able to work at their rated frequency. To reduce the number of non-booting boards, I chose to take the conservative approach, which is also enforced by the limits of the point 1

Changing the dram frequency is not an easy task: you need the right ddrbin (the binary piece of code that initializes the DRAM), recompile u-boot, glue them together with the trust os to produce the idbloader and finally install it at sector 0x40 of the flash/sdcard.

 

This is all done automatically by armbian scripts, so you can read the code to make your way through.

 

BTW, I'm taking in consideration to experiment with the ARM trusted firmware (ATF) and maybe in the future activate the DMC kernel driver to allow reclocking.

 

Hi, I've tried to make a new ddrbin using the rockchip tools in their github but no luck it doesn't boot.

[jock]

21 hours ago, Yeoj Henrie Sayadi said:

Hi, I've tried to make a new ddrbin using the rockchip tools in their github but no luck it doesn't boot.

This may be helpful to you: https://github.com/armbian/build/blob/37b50f154af402fbe2930be5ed23a9923292f2d4/config/sources/families/rk322x.conf#L45

 

In particular you need line 60 and 61, then write the resulting binary at location 0x40 on the sdcard. Don't do this directly on the eMMC because in case something goes wrong you brick the box and will need the unbrick procedure!

[microsolar]

Hi, 

 

I like use i2c with RK3229 box. 

 

https://github.com/harbaum/I2C-Tiny-USB

 

I can't find the the kernel models for

 

i2c-tiny-usb

 

any suggestions