On 09/04/2014 01:10 PM, Denys Dmytriyenko wrote:
On Thu, Sep 04, 2014 at 10:55:02AM -0500, Robert Nelson wrote:
On Thu, Sep 4, 2014 at 10:48 AM, Denys Dmytriyenko <[email protected]> wrote:
On Thu, Sep 04, 2014 at 10:37:24AM -0500, Peter A. Bigot wrote:
On 09/04/2014 10:00 AM, Denys Dmytriyenko wrote:
On Thu, Sep 04, 2014 at 02:50:03PM +0000, Mikhail Zakharov wrote:
On Wed, Sep 3, 2014 at 8:59 PM, Peter A. Bigot <[email protected]> wrote:
One anomaly I've found is the CPU frequency range. On debian we have:
debian@beaglebone:~$ cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
300000 600000 800000 1000000
while on OE we have:
root@beaglebone:~# cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
300000 600000 720000 800000
Stock yocto-bsp is missing a few things that can be found in Robert
Nelson's patchset for 3.14 linux kernel.
There are lots of other functionality that is missing from yocto-bsp
kernel for Beaglebone. I suggest you take at the following repos and
scavenge for what you need :P
First of all, this is meta-ti mailing list for the corresponding BSP. That's
what Peter was asking for, comparing to Robert's Debian and Yocto reference
BSPs, not the other way around.
Second, Yocto reference BSP is that way for a reason - it's a reference BSP
done with pure mainline kernel and u-boot components w/o any patching on top.
That's its entire purpose. For anything else special, including performance
tweaks, there are other BSPs available. If there is an issue with performance
in meta-ti, we'll investigate it and try to match with Robert's BSP.
Yes, at this time meta-ti's BSP performs as well as I've seen any
OE-based system, and gets several things right that meta-yocto-bsp
does not (and one thing wrong that meta-yocto-bsp gets right, I
think; still investigating, will follow-up when I'm sure).
I've also verified that performance with a native gcc 4.9.1 build on
BeagleBone with hard float is poor, so it's not due to the way OE
builds gcc. I have several competing hypotheses to test.
Can you please point to the test case you were using to measure time? I'd like
to try it with few different toolchains here as well. BTW, we are currently
using Linaro gcc-4.7.3 - I'm wondering how it performs.
But I'm still looking for a way to set the CPU frequency to the
higher values supported on Beaglebone Black. I had hoped meta-ti's
would be able to do that, since it has bone vs boneblack device
trees and u-boot detection.
Any hints where to look for clock settings?
Some of those values are considered overclocking and according to the manual
will reduce the lifespan of the part...
That's an odd statement, as the parts used on the beaglebone black are
binned and sold for 1Ghz operation.
Robert, Peter,
So, after some internal discussion, here's an update:
1. In TI kernel we do dynamic opp setting based on eFuse check in the file
arch/arm/mach-omap2/opp33xx_data.c
2. Since most of our EVMs and EVM-SKs use 2.1 Si, everything works properly
with eFuse check and dynamic opp setting.
3. But eFuse was not available in 2.0 rev of silicon, only in 2.1 rev. There
were many BBB boards made with 2.0 Si that were binned to run at 1GHz. And
older 1.0 Si revs were not 1GHz capable. Currently checking with HW and
marketing teams if all/most 2.0 chips are safe to run at 1GHz... As w/o eFuse
there's no way to determine if the chip is 1GHz capable or not.
4. If your BBB board has 2.1 Si rev, then you should get 1GHz automatically.
We'll try to figure something out for 2.0 Si boards, but setting opps
statically in dts is considered incorrect and risky...
Thank you for the update; that makes many things more clear.
I normally develop using an old rev A5C BBB in a jig with a breadboard
attached, and never saw the faster speed listed as available. Today to
make it easier to compare variations without constantly rebooting, I
started running yocto-bsp on that board, and pulled out a rev B BBB on
which I'm running meta-ti's kernel. On that one the 1GHz option has
suddenly shown up.
Indeed, the A5C has a 962A chip which is Si 2.0, while the B has a 962B
chip that is Si 2.1, per SPRZ360F.
I really thought I was losing it there....
(And no, that didn't fix the performance issue, though it's down to
7m43s under meta-ti+Yocto compared to Debian's 4m54s. Current
hypothesis under test is a GCC performance regression between 4.6 and
4.9.1.)
Peter
--
_______________________________________________
meta-ti mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-ti
