Kernel 3.10 for testing (no aufs yet)

[moonman]

Here's the new kernel for testing
BFS is included, but no aufs3 patch as it isn't available for 3.10 yet.

$this->bbcode_second_pass_code('', 'pacman -U http://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kernels/3.10.0/linux-kirkwood-3.10.0-1-arm.pkg.tar.xz http://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kernels/3.10.0/linux-headers-kirkwood-3.10.0-1-arm.pkg.tar.xz')

For interested the patch is here: $this->bbcode_second_pass_code('', 'http://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/kernels/3.10.0/archlinuxarm.patch')

[bz31]

Thanks moonman for the patch.

[ebbix]

Was the patch difficult to rebase this time?
Short question concerning general kernel status:
Are there any plans on moving to device tree yet? It would make patching a lot easier and would bring nice features, too.
(My GoFlex Net is idling at 400 MHz most of the time, cpufreq is really nice to have )
Upstream kernel has had a lot of device tree changes (new boards) recently; I have created a Pogoplug v4/Mobile device tree file and plan on submitting it to upstream soon (possibly for 3.12 since I'm waiting for cool changes to be mainlined in 3.11 to eliminate the need of supplementary board-xxx.c files)

Are there any plans on using device tree exclusively in the future? Main problems would be the old bootloader, but this could be solved by stitching the blob into zImage and creating uImage out of this stitched image. That would however require an install script to stitch the correct blob based on the machine (using arcNumber to determine and fallback blob on failure?)

[moonman]

The only problem was that they've added a bunch of new devices so the patch was't applying to Kbuild and Makefile for kirkwoods.
device tree is nice but we are still missing GF Home/PP E02 to name a few. Also many people don't have a proper ArcNumber set so these things make it more difficult to migrate to device tree.

[kalganov]

For those who want to have CPUFreq I share a patch for kirkwood-cpufreq which removes dependency to DT/OF thus making possible to have CPUFreq on devices without DT support. Tested on Pogo V4 with Linux Kernels 3.10.3-3.10.4-3.10.5.
$this->bbcode_second_pass_code('', 'http://pastebin.com/EPZXZfYu')

[moonman]

Thanks, I'll include it with the next release of linux-kirkwood.

[moonman]

I can't include it at this state unfortunately as it limits CPU freq to 800MHz on a 1.2GHz device (goflex in this case). Needs some work.

$this->bbcode_second_pass_code('', '[root@GoFlex ~]# cpupower frequency-info
analyzing CPU 0:
driver: kirkwood-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 5.0 us.
hardware limits: 200 MHz - 800 MHz
available frequency steps: 800 MHz, 200 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 200 MHz and 800 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
cpufreq stats: 800 MHz:100.00%, 200 MHz:0.00%
[root@GoFlex ~]# cat /proc/cpuinfo
processor : 0
model name : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1191.11
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Seagate GoFlex Home
Revision : 0000
Serial : 0000000000000000
')

[Kurlon]

Looks like that's statically set in the patch at line 189. Change the 800 to 1200 and see how it rolls. Hell, try 1400 and see if you can soft overclock that way.

[kalganov]

In fact it does not limit anything. There are two frequencies the CPU can run at - CPUCLK and DDRCLK. You choose the frequency by setting (or resetting) a bit in a register. I have associated value 200MHz with DDRCLK and 800MHz with CPUCLK (as Pogoplug has) but it could be any value you want - the values are only used in sysfs files. I agree that it would be nice to have a real values for every hw and it could be done via defines per board (the same as DT actually does).

Something like
$this->bbcode_second_pass_code('', '
#ifdef MACH_SEAGATE_WHATEVERITCALLED
#define CPUCLK (1200*1000)
#define DDRCLK (200*1000)
#else
#define CPUCLK (800*1000)
#define DDRCLK (200*1000)
#endif
')

[Kurlon]

Beat me to the punch, I was about to note the same thing after reviewing the arm-kernel discussions on the topic.