+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCKPRO64 (https://forum.pine64.org/forumdisplay.php?fid=98)
+--- Forum: Linux on RockPro64 (https://forum.pine64.org/forumdisplay.php?fid=101)
+--- Thread: 0.7.9 Linux release from ayufan (/showthread.php?tid=6308)
RE: 0.7.9 Linux release from ayufan - Bullet64 - 11-17-2018
The system is running
Docker Image is without an desktop.https://docker-curriculum.com/
RE: 0.7.9 Linux release from ayufan - nuumio - 11-19-2018
(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 532GB 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]: 0x00So 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=offI 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.
RE: 0.7.9 Linux release from ayufan - Deathcrow - 12-04-2018
(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
@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!
RE: 0.7.9 Linux release from ayufan - nuumio - 12-04-2018
(12-04-2018, 12:37 PM)Deathcrow Wrote: @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).
RE: 0.7.9 Linux release from ayufan - Deathcrow - 12-04-2018
(12-04-2018, 02:03 PM)nuumio Wrote:(12-04-2018, 12:37 PM)Deathcrow Wrote: @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
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/5Even 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?
RE: 0.7.9 Linux release from ayufan - Deathcrow - 12-06-2018
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
gpuNot 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/policyWith 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?
RE: 0.7.9 Linux release from ayufan - dukla2000 - 12-06-2018
(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/LinuxRE: 0.7.9 Linux release from ayufan - Deathcrow - 12-12-2018
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.
RE: 0.7.9 Linux release from ayufan - Luke - 02-25-2019
Old, unstuck and locked. New pre-release thread here.