0.7.9 Linux release from ayufan

[Bullet64]

The system is running Docker Image is without an desktop.

https://docker-curriculum.com/

[nuumio]

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.

[Deathcrow]

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.

@nuumio: 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!

[nuumio]

@nuumio: 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).

[Deathcrow]

@nuumio: 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?

[Deathcrow]

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:

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?

[dukla2000]

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

[Deathcrow]

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.

[Luke]

Old, unstuck and locked. New pre-release thread here.