On Sun, Dec 29, 2013 at 1:14 PM, Robert Nelson robertcnelson@gmail.com wrote:

On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood steveu@coppice.org wrote:

...

Hi,

It looks like the BeagleBone Black is still running at 550MHz with the latest Fedora 20. Does anyone know what is holding it back from running at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a version of uboot referred to as making the BBB run at 1GHz, but when I tried experimenting with that I got the same 550MHz clock speed.

with v3.12.x: These 5 patches are needed: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

or with v3.13-rcX: https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002...

ps, while your at it, also add: https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0001...

to get the full kms experience over hdmi with the CONFIG_DRM_TILCDC/CONFIG_DRM_I2C_NXP_TDA998X

Since they are both dts patches, you don't even have to rebuild the kernel, just patch the dtb file..

Regards,

On Sun, Dec 29, 2013 at 4:13 PM, Nigel Sollars nsollars@gmail.com wrote:

Hi all,

Hey Robert do you have a rc ( 3.13 ) kernel rolled?.

I do..

https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13

Just waiting for rc6 to fall, before i push it out to building farm..

The config is really minimal right now, going to throw the kitchen sink at it tomorrow so v3.12.x users won't be missing stuff.

Regards,

On Fri, Jan 17, 2014 at 3:52 AM, Peter Robinson pbrobinson@gmail.com wrote:

On Sun, Dec 29, 2013 at 7:14 PM, Robert Nelson robertcnelson@gmail.com wrote:

...

On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood steveu@coppice.org wrote:

...

Hi,

It looks like the BeagleBone Black is still running at 550MHz with the latest Fedora 20. Does anyone know what is holding it back from running at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a version of uboot referred to as making the BBB run at 1GHz, but when I tried experimenting with that I got the same 550MHz clock speed.

with v3.12.x: These 5 patches are needed: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

or with v3.13-rcX: https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002...

I've enabled the generic cpufreq support, we had it disabled as when it first landed it had problems.

The BBB is booting with 3.13rc8 with no patches but there's a few issues I need to resolve this week with USB so I'll review that for the BB patchset to make sure it's there. Is it queued to go upstream for 3.14?

3.14 is closed, I'm cleaning my patches listed in that repo and planning to post to l-a/l-o after v3.14-rc1 hits..

Talking with CircuitCo, they would prefer the default pinmux to be setup like so:

http://elinux.org/Basic_Proto_Cape

So i'm adding those changes to the push too..

Regards,

...

It looks like the BeagleBone Black is still running at 550MHz with the latest Fedora 20. Does anyone know what is holding it back from running at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a version of uboot referred to as making the BBB run at 1GHz, but when I tried experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch kernel [1] on your BBBlack. It should add freq scaling support and you should be able to tell if it detects it appropriately if the cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 300000 600000 800000 1000000

Even with 3.12.8 you can manually load that module and it works but you only get up to 720mhz.

Peter

[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl...

On 01/22/2014 04:14 AM, Peter Robinson wrote:

...

...

...

It looks like the BeagleBone Black is still running at 550MHz with the latest Fedora 20. Does anyone know what is holding it back from running at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a version of uboot referred to as making the BBB run at 1GHz, but when I tried experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch kernel [1] on your BBBlack. It should add freq scaling support and you should be able to tell if it detects it appropriately if the cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 300000 600000 800000 1000000

Even with 3.12.8 you can manually load that module and it works but you only get up to 720mhz.

Peter

...

[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl...

Earlier Jos Vos reported the following results for his BeagleBoneBlack running pystone.py

Fedora: Pystone(1.1) time for 50000 passes = 10.9073 This machine benchmarks at 4584.1 pystones/second

Debian: Pystone(1.1) time for 50000 passes = 4.38 This machine benchmarks at 11415.5 pystones/second

Before this latest kernel I was getting results a few percent slower than he reported for Fedora. With this new kernel RPM I get

Pystone(1.1) time for 50000 passes = 6.23986 This machine benchmarks at 8013.01 pystones/second

That speed is very consistent across runs of the test. The speed has increased, but it seems to still be well below that of Debian. If I use

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

While the machine is idle it says 300MHz. While pystone.py is running it says 1GHz. When the machine is idle, top says the CPU is around 1% loaded. When pystone.py is running it says it is 99.x% loaded. As far as I can tell the clock jumps from 300MHz to 1GHz as pystone.py starts up - i.e there is no substantial lag, resulting in half the test running at 300MHz and half at 1GHz.

If my board really is now running pystone.py at 1GHz, I wonder what else could be causing this test to be around 50% slower than with Debian.

Well at least in the short term we've nearly doubled the speed.... one step at a time :-)

What is the SD card you are using and are they the same? I suspect that will have some effect too. You'd also need to look at the patch set Debian uses, with 3.13 we're pretty close to mainline in terms of the patch set and other than the OPP dtb patch there's nothing there that should really have much effect on performance. My guess would possibly be something DMA related, or maybe Debian has a patch that improved memory timings, or similar.

What sort of things does pystone measure? I've never used it. Can you get it to break the tests it does down so you can compare the different components of the test, this might give us a better idea where to look. What about one of the other test suites like phoronix-test-suite?

Peter

Hi Robert,

...

Fedora: Pystone(1.1) time for 50000 passes = 10.9073 This machine benchmarks at 4584.1 pystones/second

Which governor are you using? It seems to be definitely stuck at 300Mhz

# cpupower frequency-info analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz (asserted by call to hardware).

3.13.0-bone4 (what i'm shipping to debian bone users..)

kernel-3.13.0-1.1.fc20.armv7hl

[root@bblack ~]# cpupower frequency-info analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz (asserted by call to hardware). [root@bblack ~]# /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 6.20305 This machine benchmarks at 8060.55 pystones/second [root@bblack ~]# cpupower frequency-set -f 600000 Setting cpu: 0 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 10.6237 This machine benchmarks at 4706.45 pystones/second [root@bblack ~]# cpupower frequency-set -f 800000 Setting cpu: 0 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 7.76076 This machine benchmarks at 6442.67 pystones/second [root@bblack ~]# cpupower frequency-set -f 1000000 Setting cpu: 0 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 6.16087 This machine benchmarks at 8115.74 pystones/second [root@bblack ~]# cpupower frequency-info analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor "userspace" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware).

So it appears to work but the results are some what variable. Also I presume you've got the cpufreq driver built in rather than a module as it doesn't auto load.

Peter

Hi Robert,

On 01/22/2014 10:59 PM, Robert Nelson wrote:

On Tue, Jan 21, 2014 at 10:09 PM, Steve Underwood steveu@coppice.org wrote:

...

Hi Peter,

On 01/22/2014 04:14 AM, Peter Robinson wrote:

...

...

...

It looks like the BeagleBone Black is still running at 550MHz with the latest Fedora 20. Does anyone know what is holding it back from running at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a version of uboot referred to as making the BBB run at 1GHz, but when I tried experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch kernel [1] on your BBBlack. It should add freq scaling support and you should be able to tell if it detects it appropriately if the cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 300000 600000 800000 1000000

Even with 3.12.8 you can manually load that module and it works but you only get up to 720mhz.

Peter

...

[1] http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl...

Earlier Jos Vos reported the following results for his BeagleBoneBlack running pystone.py

Fedora: Pystone(1.1) time for 50000 passes = 10.9073 This machine benchmarks at 4584.1 pystones/second

Which governor are you using? It seems to be definitely stuck at 300Mhz

3.13.0-bone4 (what i'm shipping to debian bone users..)

# cpufreq-set --freq 300000 # /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 11.37 This machine benchmarks at 4397.54 pystones/second

# cpufreq-set --freq 600000 # /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 5.67 This machine benchmarks at 8818.34 pystones/second

# cpufreq-set --freq 800000 # /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 4.28 This machine benchmarks at 11682.2 pystones/second

# cpufreq-set --freq 1000000 # /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 3.35 This machine benchmarks at 14925.4 pystones/second

When just leaving the ondemand govenor set:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 300 MHz:0.00%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:100.00%

# /usr/lib/python2.7/test/pystone.py Pystone(1.1) time for 50000 passes = 3.39 This machine benchmarks at 14749.3 pystones/second

Regards,

On my BeagleBoneBlack running Peter's new Linux 3.13.0 RPM I get:

[root@beagle]# cpupower frequency-info analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor "userspace" may decide which speed to use within this range. current CPU frequency is 300 MHz (asserted by call to hardware).

[root@beagle]# cpupower frequency-set -f 300MHz [root@beagle]# ./pystone.py Pystone(1.1) time for 50000 passes = 22.0034 This machine benchmarks at 2272.37 pystones/second

[root@beagle]# cpupower frequency-set -f 600MHz [root@beagle]# ./pystone.py Pystone(1.1) time for 50000 passes = 10.4669 This machine benchmarks at 4776.98 pystones/second

[root@beagle]# cpupower frequency-set -f 800MHz [root@beagle]# ./pystone.py Pystone(1.1) time for 50000 passes = 7.81685 This machine benchmarks at 6396.44 pystones/second

[root@beagle]# cpupower frequency-set -f 1000MHz [root@beagle]# ./pystone.py Pystone(1.1) time for 50000 passes = 6.36032 This machine benchmarks at 7861.24 pystones/second

So, the results scale nicely with the clock speed, but all the results are around half as fast as your result at the same clock speed.

Regards, Steve