On Thu, Sep 4, 2014 at 8:55 AM, Peter A. Bigot <[email protected]> wrote: > On 09/04/2014 10:48 AM, Denys Dmytriyenko 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. > > > > The context is: > http://scruss.com/blog/2013/09/23/beaglebone-black-slow-as-a-dog/ > > The specific application is: http://www.cs.utah.edu/~aek/code/card.cpp > > The "ought to work" compiler line is: g++ -Ofast card.cpp -o card > > The "kitchen-sink-still-doesn't-help" compiler line is: > > g++ \ > -march=armv7-a -mtune=cortex-a8 \ > -mthumb-interwork \ > -mfloat-abi=hard -mfpu=neon \ > -Ofast \ > -o card \ > card.cpp > > All my tests are with gcc-4.9.1, with or without the openembedded-core patch > set. >
can you profile run it.? As i understand, you have exact same hardware and same way of running it with two different rootfs. > >> >>> 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... > > > So the Beagle Bone Black SRM's claim that the AM3358BZCZ100 can run at 1GHz > is not entirely true? Or is it just that the operating-points in that patch > are too aggressive? > > Peter > > -- > _______________________________________________ > meta-ti mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/meta-ti -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
