11-17-2018, 03:26 AM
11-19-2018, 08:04 AM
(09-02-2018, 07:16 AM)dukla2000 Wrote: [ -> ](08-31-2018, 12:05 PM)Deathcrow Wrote: [ -> ]Now to my question: Is it possible to get the eMMC module to work with linux-mainline kernel (4.18-rc8)? I encounter the following error:
...
I also tried to compile kernel for myself and tried the torvalds 4.19 sources. Both with similar results. 4.4 kernel works without problems.
...
Is usage of eMMC module currently impossible with mainline kernel?
I have the exact same fault with 4.18 rc8 from Ayufan, never a problem with 4.4. I suspect it is fixable - my guess is something DTS? But way beyond my skills so have to sit and wait. (I was gonna wait till Ayufan does a 4.18 "final" release and then figure a thread on what works/does not at 4.18. Because the memory and NVMe stuff is really enticing, it is a question if I can work around the limitations. e.g. also lots of modules missing in Ayufan rc builds, e.g. btusb)
I had these same problems too with 32GB Foresee card + mainline kernel. Two 16GB Foresee cards were working just fine. After comparing boot logs I found out that 32GB Foresee card supports command queue (CMDQ) but 16GB ones don't. CMDQ support also be checked with mmc command.
Here's a snippet from boot log ("Command Queue Engine enabled" gave it away, it was missing from boot with 16GB card):
Code:
$ grep mmc1 bootlog-4.19.0-1073-ayufan-ga6e013135a6e.txt | head
[ 3.635052] mmc1: CQHCI version 5.10
[ 3.661556] mmc1: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[ 3.719489] mmc1: Command Queue Engine enabled
[ 3.720004] mmc1: new HS200 MMC card at address 0001
[ 3.721546] mmcblk1: mmc1:0001 NCard 28.9 GiB
[ 3.722177] mmcblk1boot0: mmc1:0001 NCard partition 1 4.00 MiB
[ 3.722961] mmcblk1boot1: mmc1:0001 NCard partition 2 4.00 MiB
[ 3.723748] mmcblk1rpmb: mmc1:0001 NCard partition 3 4.00 MiB, chardev (236:0)
[ 4.016480] mmc1: running CQE recovery
[ 64.505863] mmc1: cqhci: timeout for tag 5
32GB card's CMDQ as seen by mmc command (be carefull with it if you use other commands than 'extcsd read', man says many of them cause "one-time programmable (unreversible) changes"!):
Code:
$ sudo mmc extcsd read /dev/mmcblk1 | grep CMDQ
Command Queue Support [CMDQ_SUPPORT]: 0x01
Command Queue Depth [CMDQ_DEPTH]: 8
Command Enabled [CMDQ_MODE_EN]: 0x00
So I guessed CMDQ was the problem and decided to add a new kernel command line parameter which could be used to disable CMDQ. After little kernel hacking (mmc: core: Add MMC Command Queue Support kernel parameter) and new parameter added to command line:
Code:
$ dmesg | egrep "Linux version|mmc1"
[ 0.000000] Linux version 4.19.0-dev (nuumio@cmbuilder) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #10 SMP PREEMPT Mon Nov 19 13:34:57 EET 2018
[ 4.226195] mmc1: CQHCI version 5.10
[ 4.252623] mmc1: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[ 4.315567] mmc1: CMDQ support disabled in kernel
[ 4.316014] mmc1: new HS200 MMC card at address 0001
[ 4.317121] mmcblk1: mmc1:0001 NCard 28.9 GiB
[ 4.317923] mmcblk1boot0: mmc1:0001 NCard partition 1 4.00 MiB
[ 4.318831] mmcblk1boot1: mmc1:0001 NCard partition 2 4.00 MiB
[ 4.319497] mmcblk1rpmb: mmc1:0001 NCard partition 3 4.00 MiB, chardev (236:0)
$ sudo mmc extcsd read /dev/mmcblk1 | grep CMDQ
[sudo] password for rock64:
Command Queue Support [CMDQ_SUPPORT]: 0x01
Command Queue Depth [CMDQ_DEPTH]: 8
Command Enabled [CMDQ_MODE_EN]: 0x00
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mtdblock0 31:0 0 4M 0 disk
mtdblock1 31:1 0 32K 0 disk
mtdblock2 31:2 0 256K 0 disk
mmcblk1 179:0 0 28.9G 0 disk
|-mmcblk1p1 179:1 0 3.9M 0 part
|-mmcblk1p2 179:2 0 64K 0 part
|-mmcblk1p3 179:3 0 4M 0 part
|-mmcblk1p4 179:4 0 4M 0 part
|-mmcblk1p5 179:5 0 4M 0 part
|-mmcblk1p6 179:6 0 112M 0 part /boot/efi
`-mmcblk1p7 179:7 0 28.8G 0 part /
mmcblk1boot0 179:32 0 4M 1 disk
mmcblk1boot1 179:64 0 4M 1 disk
$ head /boot/extlinux/extlinux.conf
timeout 10
menu title select kernel
default kernel-4.19.0-dev
label kernel-4.19.0-dev
kernel /boot/vmlinuz-4.19.0-dev
initrd /boot/initrd.img-4.19.0-dev
devicetreedir /boot/dtbs/4.19.0-dev
append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 mmc_cmdqueue=off
I now have 32GB Foresee card working with mainline kernel. Of course there's the trouble of manually adding the new parameter to extlinux.conf but it's certainly less annoying than non-booting system This is not a fix for the problem and I don't know if the real problem is with eMMC card, driver or RP64 itself. But at least there's now a workaround. I'm just about to open a pull request for the change to ayufan's repo so it can be merged if seen appropriate.
12-04-2018, 12:37 PM
(11-19-2018, 08:04 AM)nuumio Wrote: [ -> ]I now have 32GB Foresee card working with mainline kernel. Of course there's the trouble of manually adding the new parameter to extlinux.conf but it's certainly less annoying than non-booting system This is not a fix for the problem and I don't know if the real problem is with eMMC card, driver or RP64 itself. But at least there's now a workaround. I'm just about to open a pull request for the change to ayufan's repo so it can be merged if seen appropriate.
12-04-2018, 02:03 PM
(12-04-2018, 12:37 PM)Deathcrow Wrote: [ -> ]: Your patch works perfectly for me! Thank you for posting it. I was tinkering around with device tree files but gave up after a while, even though I had an inkling that it was related to CMDQ!
You're welcome Check #Rock64 irc logs from last Saturday and Sunday too. stikonas had a different patch that removed CMDQ from Arasan driver. That one works too (tried it on 4.20-rc4).
12-04-2018, 03:58 PM
(12-04-2018, 02:03 PM)nuumio Wrote: [ -> ](12-04-2018, 12:37 PM)Deathcrow Wrote: [ -> ]: Your patch works perfectly for me! Thank you for posting it. I was tinkering around with device tree files but gave up after a while, even though I had an inkling that it was related to CMDQ!
You're welcome Check #Rock64 irc logs from last Saturday and Sunday too. stikonas had a different patch that removed CMDQ from Arasan driver. That one works too (tried it on 4.20-rc4).
Neat, I'll probably check it out when the kernel is out of rc state.
Something else I noticed, the big cores seem to be throttling a lot:
Code:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St.
22:58:03: 816/1416MHz 6.05 91% 5% 4% 80% 0% 0% 52.2°C 0/5
Even though the CPU is only at 52.2°C it's not going above 816 Mhz. Anyone else facing this issue? As soon as I stop compiling something (... Gentoo ) the clock goes back up to 1800. Or is this conservative throttling normal with the passive cooler?
12-06-2018, 03:48 AM
I've been playing around with the thermal stuff a bit more and - unless I messed up my kernel - the thermal policy governor 'power_allocator' doesn't appear to work correctly for the 2 big cores. The kernel seems to think that they're a GPU:
Not sure if this is causing the issues, but it strikes me as odd.
Workarounds that work for me is either turning off that thermal_zone (through /sys/class/thermal/thermal_zone1/mode) or - probably safer - switching to fair_share policy:
With this change the cores stay nicely at 1.8 Ghz for me. Just to be clear: This is all with the mainline kernel. I assume it works fine with the 4.4 rockchip kernel.
Edit: Anyone got some experience with this thermals stuff? power_allocator.txt advises to set sustainable-power through the device tree, which I suspect might be too low by default. Is this roughly the right direction to go here?
Code:
/s/c/t/thermal_zone1 » cat /sys/class/thermal/thermal_zone1/type
gpu
Not sure if this is causing the issues, but it strikes me as odd.
Workarounds that work for me is either turning off that thermal_zone (through /sys/class/thermal/thermal_zone1/mode) or - probably safer - switching to fair_share policy:
Code:
echo fair_share > /sys/class/thermal/thermal_zone1/policy
With this change the cores stay nicely at 1.8 Ghz for me. Just to be clear: This is all with the mainline kernel. I assume it works fine with the 4.4 rockchip kernel.
Edit: Anyone got some experience with this thermals stuff? power_allocator.txt advises to set sustainable-power through the device tree, which I suspect might be too low by default. Is this roughly the right direction to go here?
12-06-2018, 01:47 PM
(12-06-2018, 03:48 AM)Deathcrow Wrote: [ -> ]With this change the cores stay nicely at 1.8 Ghz for me. Just to be clear: This is all with the mainline kernel. I assume it works fine with the 4.4 rockchip kernel.
Yup, I have the same frustration starting at 4.18, still there at 4.19 as per my post here.
For most of what I need mainline is cool - the scheduling is an irritation, but I really need to get sound somehow as well. Watching the noises here and on IRC seems sound is pretty close (may well be OK for others, I am still struggling )
PS - at 4.4 thermal zone1 is also gpu - agree strange but seems not the problem (on its own):
Code:
$ cat /sys/class/thermal/thermal_zone1/type
gpu-thermal
$ cat /sys/class/thermal/thermal_zone0/type
soc-thermal
$ uname -a
Linux rpro64.dukla.net 4.4.138-1100-rockchip-ayufan-g95cecee47f40 #1 SMP Sat Sep 29 15:43:04 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
12-12-2018, 04:53 PM
I just wanted to give a quick recommendation for everyone who likes Btrfs (I don't think it's worth to start a new thread for this):
Having a small ext4 boot partition (just kernel+initrd) and a large btrfs partition for the root filesystem works great. Especially with the mainline kernel: I'm currently using btrfs+zstd compression, which is fast and saves lots of space. Having the snapshot feature is really great for someone who likes to tinker with the OS and am currently keeping 7 snapshots (one for each day of the week), to which I could revert in case I mess something up. With the incremental backup feature I'm also maintaining very painless backups to external storage.
Having a small ext4 boot partition (just kernel+initrd) and a large btrfs partition for the root filesystem works great. Especially with the mainline kernel: I'm currently using btrfs+zstd compression, which is fast and saves lots of space. Having the snapshot feature is really great for someone who likes to tinker with the OS and am currently keeping 7 snapshots (one for each day of the week), to which I could revert in case I mess something up. With the incremental backup feature I'm also maintaining very painless backups to external storage.