[Free and Libre Open Source SBC List Thread]

9 hours ago, hexdump said:

boards sometimes come with wifi requiring blobs

If you care about the wifi blob, don't forget the blobs in SD-card-, EMMC-, Hardisk-, USB-stick-, Keyboard-controller, ... to have a complete system.

[How to use I2C DS1307 RTC early in boot?]

Proper dtb configuration and driver as build-in.

[Mainline VPU]

2 hours ago, Pencheff said:

DRM rendering works with X11 and GLES/EGL.

Mainline hardware acceleration does not work efficiently for X11 because it does not have a suitable ddx driver with the correct render node GPU and v4l2 mem2mem VPU support.
I discussed my results in a thread that starts here with some follow-up posts while I examine it for myself.

[Tried upgrading from slightly older (4.19.62) kernel on Cubietruck, now won't boot]

3 hours ago, TRS-80 said:

Also, I am still a little worried about the results of fsck from above. 

You referenced the raw device by "/dev/mmcblk1" where MBR , u-boot and partitions reside.
You need to reference a partition by "/dev/mmcblk1pX" where a suitable filesystem resides.
Replace "X" with the number of the partition you want to check.

[Rock64 enable 1-wire to read DS18B20 or Dallas temperature sensor]

10 hours ago, martinayotte said:

Alternatively, it is possible maybe to workaround by editing main DT instead of using overlay.

Or, apply overlay static to base blob.

fdtoverlay --help

Much easier 

[Helios64 Support]

9 hours ago, fromport said:

Crashed within _minutes_

It was only a shot in the dark. I was inspired by this post. Attempting to trigger a next frequency change while a previous one is still in progress would have been a good explanation, as the crash appears to occur through dynamic frequency scaling. But having this configuration right is a good idea in any case. It's not always about it working or not. Most of the time, it's about not working as well as possible and all the small drawbacks add up in overall performance.

[Helios64 Support]

Out of curiosity, with mainline kernel and ondemand governor in place.
Apply this:

echo 40000 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate
echo 465000 > /sys/devices/system/cpu/cpufreq/policy4/ondemand/sampling_rate

Does it still crash in your use case?
If it does not crash any longer I will explain what is going on.

[CSC Armbian for RK322x TV box boards]

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.

[How to control FAN on Rockpro64?]

2 hours ago, GreyLinux said:

any direction , advice or information  would be appreciated

For a first test replace your rk3399-rockpro64.dtb by the one provided in this  post. 

If your original dtb is carriing different configuration you can use the fdtoverlay method to apply rk3399-rockpro64-tz.dtbo (build from rk3399-rockpro64-tz.dts) static to your base dtb. This will work with mainline fdtoverlay without modification. Using it as dynamic overlay should also work.
The second rk3399-rockpro64-tz.dts post was only to showcase how to change a value of an existing binding.

[CSC Armbian for RK322x TV box boards]

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.

[CSC Armbian for RK322x TV box boards]

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.

[Single Armbian image for RK + AML + AW (aarch64 ARMv8)]

...

 

[Moderating question]

1 hour ago, DevShanky said:

Pirated? I am sure I am missing some thing here.

English is probably not balbes150 native language and he is using a translator.
"Hijacked" would be a better translation, your post is off topic in that thread.

[CSC Armbian for RK322x TV box boards]

4 hours ago, jock said:

Do you know what are the capabilities of the rockchip/designware DRM IP?

For the details you have to read the TRM (e.g.) of the specific device.

 

4 hours ago, jock said:

VOP

VOP is how Rockchip is calling the display subsystem components.

 

4 hours ago, jock said:

Do RGA, which I guess is the 2D GPU for rockchip, has any role in this and currently do any acceleration for pixel format conversion?

It is as mem2mem exposed and is e.g. usable for hardware accelerated video scaling in video pipelines.

 

2 hours ago, hexdump said:

how about a wayland compositor and xwayland in it to run x apps

Sorry, you are to late in the game 

 

On 9/10/2020 at 5:52 PM, usual user said:

I gave up xorg and switched to plasma-desktop. Kwin is supporting a wayland backend and so I get a lightning fast graphics desktop with all bells and whistles.

With my current setup, as soon as the memory pressure issue is resolved, I am feature complete.

[CSC Armbian for RK322x TV box boards]

4 hours ago, jock said:

At the moment I'm considering to ship a default configuration of this kind

That configuration looks sane to me.

 

4 hours ago, jock said:

just basic KMS acceleration

That is the problem, basic KMS/drm acceleration does not suffice. You need the full set to be efficient. E.g. to have also accelerated video output from the VPUs and moving an entire frame buffer for only a line scroll somewhere on the screen is very inefficient. But any drm IP has different capabilities. Take for example i.MX6, the drm IP has very little capabilities but a separate 2D GPU. And the 3D GPU renders in a format that can't be scaned out by the drm IP. It has to be converted by the 2D GPU first. This is something modesetting can't cope with and probably the reason why the armada driver exists.
I don't know why no suitable driver is available for Xorg because code already exists for Wayland drm backends. Perhaps the structure of Xorg is not suitable to implement it in a similar way, or the relevant developers have moved to Wayland already.

 

4 hours ago, jock said:

I still have the annoying issue with the cursor being "stuck" during heavy CPU load. This kind of problem is also shared with weston on panfrost (on rk3288), and I'm really puzzled if there is something misconfigured on my side or there is still something wrong in the drivers.

I had to switch to kernel 5.9.0-rc5 with some panfrost patches from linux-next on top. For Mesa I'm using current master branch. With this in place I get a flawless working. The only issue left is some sort of memory pressure on heavy GPU use:

Spoiler

[335437.771871] panfrost_gem_shrinker_scan: 4 callbacks suppressed
[335437.771877] Purging 524288 bytes
[335440.144408] Purging 4194304 bytes
[335440.170420] Purging 4325376 bytes
[335440.206017] Purging 655360 bytes
[335440.224655] Purging 4337664 bytes
[335442.905745] Purging 528384 bytes
[335469.221833] Purging 585728 bytes
[335469.230491] Purging 4337664 bytes
[335469.291804] Purging 4194304 bytes
[335469.314880] Purging 4583424 bytes
[335470.128892] Purging 524288 bytes
[335470.141290] Purging 610304 bytes
[335470.151784] Purging 528384 bytes
[335470.160796] Purging 4194304 bytes
[335470.334194] Purging 720896 bytes
[335471.603038] Purging 675840 bytes
[335475.871009] panfrost_gem_shrinker_scan: 3 callbacks suppressed
[335475.871016] Purging 540672 bytes
[335475.884016] Purging 540672 bytes
[335475.895508] Purging 524288 bytes
[335475.904032] Purging 524288 bytes
[335475.916646] Purging 548864 bytes
[335475.924438] Purging 540672 bytes
[335475.932830] Purging 544768 bytes
[335475.937817] Purging 548864 bytes
[335476.615346] Purging 540672 bytes
[335476.620240] Purging 540672 bytes
[335489.987048] panfrost_gem_shrinker_scan: 13 callbacks suppressed
[335489.987051] Purging 610304 bytes
[335489.995387] Purging 524288 bytes
[335490.005181] Purging 4620288 bytes
[335490.016824] Purging 4493312 bytes
[335490.082926] Purging 659456 bytes
[335490.134630] Purging 528384 bytes
[335512.840731] Purging 524288 bytes

 

But development is a moving target and I see this which looks somehow related.

[CSC Armbian for RK322x TV box boards]

On 9/13/2020 at 3:51 PM, jock said:

had to blacklist lima module to get good 2D desktop experience

lima is not the culprit, it is modesetting which uses it improperly.
Disable it for modesetting by:

Section "Device"
        Identifier      "KMS-1"
        Driver          "modesetting"
        Option          "AccelMethod"           "none"
EndSection

and leave lima in place so e.g. kodi-gbm and Wayland compositors can make use of it.

You should also include a stanza like this:

Section "OutputClass"
        Identifier      "dwhdmi-rockchip"
        MatchDriver     "rockchip"
        Option          "PrimaryGPU"    "TRUE"
EndSection
Section "OutputClass"
        Identifier      "Meson-IP"
        MatchDriver     "meson"
        Option          "PrimaryGPU"    "TRUE"
EndSection
Section "OutputClass"
        Identifier      "Exynos-IP"
        MatchDriver     "exynos"
        Option          "PrimaryGPU"    "TRUE"
EndSection

so that modesetting immediately selects the correct /dev/dri/cardX node for the display subsystem, without autoprobing and guessing. Haveing all stanzas for the drivers you want to support in place simultaniously does no harm because any device is equipped with one IP and only that one will match.

[How to control FAN on Rockpro64?]

13 hours ago, soerenderfor said:

can explain it in another way

ftdoverlay is a convenient way to apply an overlay staticly to a base dtb. You spare the DTC decompile - manually edit - DTC compile dance. Usually you write overlays with label refernces, but to be able to apply such an overlay, the base dtb has to be compiled with the @-option. This has significant impact on the size and distributions usually don't do this. When you write the overlay with full paths, it contains all the information to be applied to a base dtb that was not created with the @-option. The mainline ftdoverlay need the patch to be able to apply it.

 

13 hours ago, Dunc4n1d4h0 said:

Please, tell me how to change that to value that fits my needs

Edit the pwms property to any value you like as shown in the provided rk3399-rockpro64-tz.dts (50000 default changed to 10000).

[How to control FAN on Rockpro64?]

9 hours ago, Dunc4n1d4h0 said:

For me problem here is hardcoded pwm frequency

There is nothing hardcoded, there is only a default value. And as one value does not fit them all, you have to set it to the value that fits your need. See rk3399-rockpro64-tz.dts for reference. Unfortunately you cannot apply this with mainline ftdoverlay because it does not support full path notion for a reference to another node. But with fdt_overlay.patch.txt applied it is working as expected.

[How to control FAN on Rockpro64?]

The right way to use the fan would be to have a proper thermal setup (rk3399-rockpro64-tz.dts) in the devicetree. With this the kernel thermal system can handle the management.

This is a visualisation of a tmon log documenting the working of the thermal system:

Spoiler

rk3399-rockpro64.dtb is a mainline dtb with rk3399-rockpro64-tz.dtbo applied via:

fdtoverlay --input rk3399-rockpro64.dtb --output rk3399-rockpro64.dtb rk3399-rockpro64-tz.dtbo

See if this is working for you by replacing your dtb and check with tmon.

[CSC Armbian for RK322x TV box boards]

4 hours ago, nokirunner said:

but anyway I gave up, I tried for a couple of days to "try my luck by experimenting"

I gave up xorg and switched to plasma-desktop. Kwin is supporting a wayland backend and so I get a lightning fast graphics desktop with all bells and whistles. Ok the bugs at the panfrost stack still exist but this environment makes efficient use of anything that is available. Thanks to the configurability of kwin, I can have the same look and feel of my previous desktop.

[Thermal Throtteling not working in 5.3 and 5.4 kernel on Orange Pi Zero Plus]

12 minutes ago, linuxjosef said:

Definitely thermal, the armbianmonitor benchmark was running the whole time.

AFAIK armbianmonitor does not log the cooling devices, hence my request for the tmon log.

[Thermal Throtteling not working in 5.3 and 5.4 kernel on Orange Pi Zero Plus]

3 hours ago, linuxjosef said:

throttling in principle works

Is the throttling triggered by thermal reasons or only by cpu load?

A tmon log will tell you if it is really thermal throttling.

[Thermal Throtteling not working in 5.3 and 5.4 kernel on Orange Pi Zero Plus]

A tmon log would be interesting to see how the thermal system performs.

[CSC Armbian for RK322x TV box boards]

Inspired by you, I have also done some more tests on my site.

18 hours ago, jock said:

freezed after the jellyfish test in fullscreen (1080p) mode

For me it is also freezing. Since I am on panfrost, we can rule out lima and panfrost for this. The one we have still in common is rockchipdrm. i.MX6 is using imxdrm and is not suffering this flaw, so IMHO the display subsystem is responsible for this error.

 

18 hours ago, jock said:

glmark2-wayland crashed after the third benchmark

I don't know how mature the lima GL support in Mesa already is, so IMHO Mesa is to blame here.
But we are dealing with 2D acceleration functions of the display subsystem for Xwindow, so these errors are not relevant for our further investigations.

 

18 hours ago, jock said:

At the moment there is a LibreELEC patch that demotes the DRM cursor plane to an overlay plane

The concept of a dedicated cursor plane is gone in atomic modesetting. The plane is handled as any other plane, but the constraints of the plane are still obeyed. The selection of a suitable cursor plane will most probably select this one, but any other one can be chosen.

[CSC Armbian for RK322x TV box boards]

On 8/28/2020 at 8:55 PM, xwiggen said:

The driver is opensourced, see https://developer.arm.com/tools-and-software/graphics-and-gaming/mali-drivers/utgard-kernel

This is only the proprietary kernel part that is already implemented in mainline via /dev/dri/renderD128. The missing functionality is how the binary bloob uses it, which must be implemented via the as yet non-existent armsoc submodule. glamor has it already but using it via modesetting is sub optimal because of KMS/drm implementation design decisions there.