Pogoplug v4 / Linux-kirkwood: Differing CPU speed

[ebbix]

I have noticed some weird behavior with my Pogoplug v4: The CPU speed seems to vary on each reboot.
Sometimes I get 795.44 BogoMIPS, sometimes 996.14 BogoMIPS. Well, BogoMIPS don't actually say something about the CPU's speed, but at least for time echo "scale=4000; a(1)*4" | bc -l (which calculates Pi with 4000 decimals) I get about 86s with 996.14 BogoMIPS vs. 108s with 795.44 BogoMIPS. When calculating 8000 decimals, I get 507s vs 634s. These values differ significantly, so I assume that the actual clock frequency varies between 1.0 GHz and 0.8 GHz (and 634 * 0.8 are roughly equivalent to 507 * 1.0).
Rootfs, kernel and device were the same during all tests.

Some relevant dmesg output (just until BogoMIPS were calculated); they seem the same except for the last line:
$this->bbcode_second_pass_code('', '[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.13.7-1-ARCH (nobody@root-armv5-copy) (gcc version 4.8.2 20131219 (prerelease) (GCC) ) #1 PREEMPT Mon Mar 24 14:05:55 MDT 2014
[ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: Pogoplug V4
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] On node 0 totalpages: 32768
[ 0.000000] free_area_init_node: node 0, pgdat c07900e8, node_mem_map c0867000
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32768 pages, LIFO batch:7
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4 rootdelay=1 quiet
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 121300K/131072K available (5487K kernel code, 333K rwdata, 1660K rodata, 259K init, 828K bss, 9772K reserved)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0702e28 (7148 kB)
.init : 0xc0703000 - 0xc0743c64 ( 260 kB)
.data : 0xc0744000 - 0xc079765c ( 334 kB)
.bss : 0xc079765c - 0xc0866874 ( 829 kB)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:114
[ 0.000000] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 25769803770ns
[ 0.000000] Console: colour dummy device 80x30
[ 9.374375] Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)')

$this->bbcode_second_pass_code('', '[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.13.7-1-ARCH (nobody@root-armv5-copy) (gcc version 4.8.2 20131219 (prerelease) (GCC) ) #1 PREEMPT Mon Mar 24 14:05:55 MDT 2014
[ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: Pogoplug V4
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] On node 0 totalpages: 32768
[ 0.000000] free_area_init_node: node 0, pgdat c07900e8, node_mem_map c0867000
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32768 pages, LIFO batch:7
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4 rootdelay=1 quiet
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 121300K/131072K available (5487K kernel code, 333K rwdata, 1660K rodata, 259K init, 828K bss, 9772K reserved)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0702e28 (7148 kB)
.init : 0xc0703000 - 0xc0743c64 ( 260 kB)
.data : 0xc0744000 - 0xc079765c ( 334 kB)
.bss : 0xc079765c - 0xc0866874 ( 829 kB)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:114
[ 0.000000] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 25769803770ns
[ 0.000000] Console: colour dummy device 80x30
[ 5.204315] Calibrating delay loop... 795.44 BogoMIPS (lpj=3977216)
')
I was booting without setting any machid in environment, but there was no difference (i.e. still differing speed) when setting F78 for Pogoplug v4.

I haven't tested stock Pogo kernel extensively (i.e. no rebooting tests were performed), but it seems this kernel always uses 1.0 GHz:
$this->bbcode_second_pass_code('', '[ 0.780000] cpufreq: Init kirkwood cpufreq driver
[ 0.780000] cpufreq: High frequency: 1000000KHz - Low frequency: 250000KHz
[ 0.780000] cpufreq: Setting CPU Frequency to 1000000 KHz
[ 0.780000] cpufreq: Setting PowerSaveState to off
')
and benchmarks show the same values as 996.14 BogoMIPS boot on linux-kirkwood kernel.

Has anyone ever noticed this before or even knows a way to fix this? (Of course I'd like it to always run in "turbo" mode)

EDIT: I did some research: My U-Boot (not ALARM chainloaded one) uses a TCLK of 166 MHz (166000000 Hz). When setting to 200 MHz (6281 default), 996.14 BogoMIPS seems to be always used (have not done enough reboots yet to definitely confirm) but U-Boot UART output is total garbage.
However, original CE U-Boot (which I had to use to boot stock Pogoplug kernel) uses 166666667 Hz, slightly higher than those 166000000 Hz. This seems to do the trick, although further testing has to be done.
EDIT²: Nope, BogoMIPS are still down at 795.44 on most boots.

EDIT³: Okay, it seems as sometimes SAR (sample at reset) register bit 1 is 1 instead of 0. This SAR register holds the CPU frequency. According to reference manual, 6192 should always have bit 1 set to 0. If this is 1, it gives a performance boost (okay, that depends on the remaining content of SAR register). So the remaining question is WHY sometimes this one bit is flipped. It is definitely not a software problem with the kernel as I initially thought.

EDIT⁴: All this happens only if UART is connected. Without UART, CPU frequency is always 800 MHz. With UART, CPU frequency is often, but not always 1000 MHz.
UART0 TXD is connected to MPP10, which -- acording to the specs -- sets SAR[1] value on reset.
So MPP10 needs to be pulled up (by overriding internal pulldown resistor) to enable 1 GHz mode...

[Sergeanter]

I saw the same thing and tried to catch bootlogs when it happened but then it stopped and now I get 800MHz on both of my units.
I have UART connected on both with some crappy discrete logic TTL to RS232 converter so it could be the same glitch with port pull up.
I was getting garbage via UART and had to add a pull up or pull down resistor ( dont remember now)
I thought I was hallucinating when I saw 1GHz. I wonder now if we can overclock it ( though working UART is probably more useful)

EDIT: I have looked at the layout and MPP6 is right in between MPP10 and MPP11( used as UART TX and RX). If MPP6 gets asserted low during reset, a pnp transistor soldered in between MPP6 and MPP10 would do the job of raising MPP10 high during reset and setting 1GHz.
Would you know if SAR register is set on leading or trailing edge of reset?

[ajzhangyu]

Thanks Sergeanter. I read this thread and found the same thing with a cheap TTL-USB converter on my V4. It is now running very stable.