Linux Kernel 4.18.8

[Bullet64]

Someone has build kernel 4.18.8

https://github.com/ddimension/linux-mainline-kernel

Code:

rock64@rockpro64:~$ uname -a
Linux rockpro64 4.18.8-77394-g8cce48cacf88 #1 SMP PREEMPT Mon Sep 17 18:50:57 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Use at your own risk!

[dukla2000]

Saw this on your forums - many thanks to av (or whoever has done the cooking)!

Seems like a couple of things are improved since rc8 (e.g. DRM-ROCKCHIP doesn't cause major delays/timeouts) - I hope you are OK if I use this thread to list problems I have with 4.18 (in fact 4.18.8 now)?

1) The video/armsoc/DRM/midgard is not quite right. Sorry my knowledge in this area is dangerous so apologies for any terminology abuses. The most obvious problem is in Xorg.log

Code:

[    36.693] (II) ARMSOC: Driver for ARM Mali compatible chipsets
[    36.693] (WW) Falling back to old probe method for armsoc
[    36.693] (II) No BusID or DriverName specified - opening /dev/dri/card0
[    36.693] (EE) ERROR: Cannot set the DRM interface version.
[    36.693] (EE) ERROR: Cannot open a connection with the DRM - Permission denied

Not sure if the early failure to bind to HDMI is significant?

Code:

$ dmesg | grep drm
[    1.419355] rockchip-drm display-subsystem: Linked as a consumer to ff8f0000.vop
[    1.420145] rockchip-drm display-subsystem: Linked as a consumer to ff900000.vop
[    1.421531] rockchip-drm display-subsystem: Linked as a consumer to ff940000.hdmi
[    1.426903] rockchip-drm display-subsystem: bound ff8f0000.vop (ops vop_component_ops)
[    1.429626] rockchip-drm display-subsystem: bound ff900000.vop (ops vop_component_ops)
[    1.430571] rockchip-drm display-subsystem: failed to bind ff940000.hdmi (ops dw_hdmi_rockchip_ops): -517
[    1.431852] rockchip-drm display-subsystem: master bind failed: -517
[    2.255270] rockchip-drm display-subsystem: bound ff8f0000.vop (ops vop_component_ops)
[    2.257496] rockchip-drm display-subsystem: bound ff900000.vop (ops vop_component_ops)
[    2.259748] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops)
[    2.260483] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.261066] [drm] No driver support for vblank timestamp query.
[    2.478338] rockchip-drm display-subsystem: fb0:  frame buffer device
[    2.480186] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0

2) Sound - no chance on HDMI but seems almost there on ES8316 but not quite again. And again my skills around sound are pathetic. The first time I try to play something with mpv the screen looks like it is playing, but nothing comes through the speakers, and dmesg has

PHP Code:

[ 1002.035173] es8316 1-0010: No sysclk provided
[ 1002.035579] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22
[ 1002.040228] es8316 1-0010: No sysclk provided
[ 1002.040628] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22
[ 1002.043697] es8316 1-0010: No sysclk provided
[ 1002.044221] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22
[ 1002.045391] es8316 1-0010: No sysclk provided
[ 1002.045787] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22
[ 1002.047267] es8316 1-0010: No sysclk provided
[ 1002.047669] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22
[ 1002.048943] es8316 1-0010: No sysclk provided
[ 1002.049340] es8316 1-0010: ASoC: can't open codec ES8316 HiFi: -22 


3) The schedulling is not right: with either ondemand or performance high CPU jobs land on the little cores. I guess CONFIG_ARM_ROCKCHIP_CPUFREQ needs to be ported from 4.4?

4) Still get an infinite loop at boot "running CQE recovery" if eMMC is plugged in

5) This seems to be a defect in the DT but I cannot find it:

Code:

$ dmesg | grep vcc_sdio
[    2.092922] vcc_sdio: Bringing 3300000uV into 3000000-3000000uV
[    2.148951] vcc_sdio: unsupportable voltage range: 3300000-3000000uV

6) Similarly think this is an attempt to define OTG on USB2 whereas it should be the USB3 ports

Code:

$ dmesg | grep otg
[    1.818420] OF: graph: no port node found in /syscon@ff770000/usb2-phy@e450/otg-port

[ddimension]

Saw this on your forums - many thanks to av (or whoever has done the cooking)!

Seems like a couple of things are improved since rc8 (e.g. DRM-ROCKCHIP doesn't cause major delays/timeouts) - I hope you are OK if I use this thread to list problems I have with 4.18 (in fact 4.18.8 now)?

3) The schedulling is not right: with either ondemand or performance high CPU jobs land on the little cores. I guess CONFIG_ARM_ROCKCHIP_CPUFREQ needs to be ported from 4.4?

4) Still get an infinite loop at boot "running CQE recovery" if eMMC is plugged in

5) This seems to be a defect in the DT but I cannot find it:

Code:

$ dmesg | grep vcc_sdio
[    2.092922] vcc_sdio: Bringing 3300000uV into 3000000-3000000uV
[    2.148951] vcc_sdio: unsupportable voltage range: 3300000-3000000uV

6) Similarly think this is an attempt to define OTG on USB2 whereas it should be the USB3 ports

Code:

$ dmesg | grep otg
[    1.818420] OF: graph: no port node found in /syscon@ff770000/usb2-phy@e450/otg-port

Thanks for your statement. Some comments:
3)
I noticed that crypto performance varies a lot and did not notice it was the missing scheduling. Interesting. But there currently no driver..
6) 
There seems to support for usb-c ports in kernel.  Perhaps I can fix it later.

Also there is another problem with sata and ssd. It is not stable, I get SATA disconnects... Normal HDD works. Do you have the same problem?

The purpose of this kernel was to stabilize my NAS, which works now as desired. Hopefully someone with more experience can fix these problems.

A funny fact is, that all other platforms get support/developement in the kernel. But not our beloved RockPro64.
See https://git.kernel.org/pub/scm/linux/ker...h=for-next

[dukla2000]

I noticed that crypto performance varies a lot and did not notice it was the missing scheduling. Interesting. But there currently no driver..

Possibly because threads tending to the little cores rather than being fixed to a big core. I think the CONFIG_ARM_ROCKCHIP_CPUFREQ in 4.4 is probably the thing we really need?  I did notice .../arch/arm64/configs/rockchip_linux_defconfig has a whole heap of CONFIG_CRYPTO parameters set Y and keep meaning to check my config. I thought the openSSL results I got from TKaiser sbc-bench were poor compared to Firefly.

Also there is another problem with sata and ssd. It is not stable, I get SATA disconnects... Normal HDD works. Do you have the same problem?

Sorry - I no longer use any SATA nor SSD (except occasionally via USB for backup!) Since getting my NVMe to work (thanks again Bullet64!) I figure that is the way to go. And I do not have that much data beyond NVMe capacities.

The purpose of this kernel was to stabilize my NAS, which works now as desired. Hopefully someone with more experience can fix these problems.

A funny fact is, that all other platforms get support/developement in the kernel. But not our beloved RockPro64.
See https://git.kernel.org/pub/scm/linux/ker...h=for-next

As soon as I posted my earlier reply with a list of 6 things that do not work I thought it was possibly too negative. The reality is that 4.18 is 99% brilliant, and having learned how to compile a kernel, playing with the CONFIG parameters is great fun. Let alone tampering with the DTS. My latest version I swapped rk3399-oppp.dtsi for rk3399-op1-opp.dtsi to get "official" 2/1.5GHz!

I do see quite a few Arm & Rockchip patches in the changelogs so am really optimistic for this SBC. For sure we need Ayufan back cooking as well and hopefully upstream some stuff if Rockchip do not.

[Yoast]

Thanks for your statement. Some comments:
3)
I noticed that crypto performance varies a lot and did not notice it was the missing scheduling. Interesting. But there currently no driver..
6) 
There seems to support for usb-c ports in kernel.  Perhaps I can fix it later.

Also there is another problem with sata and ssd. It is not stable, I get SATA disconnects... Normal HDD works. Do you have the same problem?

The purpose of this kernel was to stabilize my NAS, which works now as desired. Hopefully someone with more experience can fix these problems.

A funny fact is, that all other platforms get support/developement in the kernel. But not our beloved RockPro64.
See https://git.kernel.org/pub/scm/linux/ker...h=for-next

Thanks for compiling the kernel ddimension

My plan is to use this board as a NAS as well. You're writing that you managed to stabilize functionality. What exactly was not working for you? I'm using normal HDDs and I haven't seen SATA disconnects.

One of the things I ran into with Ayufan's 4.18 kernel was that downloading speeds via openVPN were intermittent. It kept dropping to 0 kb/s all the time. I first thought it was a 'writing to disk' issue, but downloading not through a VPN was stable at max speed. Have you seen this?

[Yoast]

I have just finished compiling this kernel and noticed the following message during booting:

Code:

[    0.000000] Number of cores (6) exceeds configured maximum of 4 - clipping

The corresponding value (CONFIG_NR_CPUS=4) can be found via menuconfig under Kernel Features --> Maximum number of CPUs.

I will change this to 6, recompile and see what happens.

[dukla2000]

The corresponding value (CONFIG_NR_CPUS=4) can be found via menuconfig under Kernel Features --> Maximum number of CPUs.

I will change this to 6, recompile and see what happens.

Mine is 64 - never seen the message .

Then again, as I am aiming for small kernel, may as well reduce to 8 in case it makes any difference.

[Takenover83]

I noticed that crypto performance varies a lot and did not notice it was the missing scheduling. Interesting. But there currently no driver..

Possibly because threads tending to the little cores rather than being fixed to a big core. I think the CONFIG_ARM_ROCKCHIP_CPUFREQ in 4.4 is probably the thing we really need?  I did notice .../arch/arm64/configs/rockchip_linux_defconfig has a whole heap of CONFIG_CRYPTO parameters set Y and keep meaning to check my config. I thought the openSSL results I got from TKaiser sbc-bench were poor compared to Firefly.

Also there is another problem with sata and ssd. It is not stable, I get SATA disconnects... Normal HDD works. Do you have the same problem?

Sorry - I no longer use any SATA nor SSD (except occasionally via USB for backup!) Since getting my NVMe to work (thanks again Bullet64!) I figure that is the way to go. And I do not have that much data beyond NVMe capacities.

The purpose of this kernel was to stabilize my NAS, which works now as desired. Hopefully someone with more experience can fix these problems.

A funny fact is, that all other platforms get support/developement in the kernel. But not our beloved RockPro64.
See https://git.kernel.org/pub/scm/linux/ker...h=for-next

As soon as I posted my earlier reply with a list of 6 things that do not work I thought it was possibly too negative. The reality is that 4.18 is 99% brilliant, and having learned how to compile a kernel, playing with the CONFIG parameters is great fun. Let alone tampering with the DTS. My latest version I swapped rk3399-oppp.dtsi for rk3399-op1-opp.dtsi to get "official" 2/1.5GHz!

I do see quite a few Arm & Rockchip patches in the changelogs so am really optimistic for this SBC. For sure we need Ayufan back cooking as well and hopefully upstream some stuff if Rockchip do not.

How is your stability/temps at 2/1.5GHz? My plex server sure could use that extra gear.

[dukla2000]

How is your stability/temps at 2/1.5GHz? My plex server sure could use that extra gear.

Short answer - fine  

Long answer: it all depends on cooling/heatsink etc. I have the stock 30mm Pine64 heatsink and no fan. At 1.8/1.4 I can run cpuminer for "a long time" (around 20C ambient) without ever getting to 80C (and so without throttling). At 2/1.5 I get to 80C and start throttling after about 15 minutes. I do have another heatsink on order that I hope will be better than the Pine 30mm one - I am loath to add a fan as the noise irritates me (which is why I was happy to downscale from Wintel!)

Also have not done a complete thrashing of the setup. I am bemused to see in the RockChip specs they mention a RK3399K which is specd at 2/1.6 as long as you keep it between 0-80C, and the RK3399 is 1.8/1.4 0-80C. My particular RK3399 has no K on the heatspreader (and does have what seems to be a January 2017 manufacturing date - 1701) and so I would be pretty sure is a bog standard RK3399. My RockPro64 is from the first 2.1 batch - I can image as volumes rise and purchasing between Pine and Rockchip gets busier this could all change.

Equally I have not yet had cause to play with the voltages but seems there is quite a bit a headroom there: the Rockchip spec is 1.25/1.20V max for the A72/A53 cores. My current DT has 2GHz @ 1.25V but I previously briefly had it at 2GHz @ 1.2V with no big problems. The "standard" RK3399 is apparently 1.8GHz @ 1.2V (in the stock DT) whereas (possibly for the K?) the "standard" device tree has 1.8GHz at 1.15V - at some stage I am tempted to try 2.1 or even 2.2 @ 1.25V. (I am less motivated to play with the LITTLE A53 cores as there is not much to gain for single threaded stuff!)

[dukla2000]

@ddimension - thanks for 4.18.9.

I enabled some CRYPTO NEON options in my config (that were previously unset) but it seems to have made very little difference to my OpenSSL results (from sbc-bench).