Being able to accurately and consistently measure the elapsed CPU time
is important for toolchain benchmarking. I ran a few experiments today
and wrote up the results at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/TimerAccuracy
The original is available at:
http://bazaar.launchpad.net/~michaelh1/linaro-toolchain-benchmarks/trunk/vi…
Short story:
* Use clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)
* The mean is unaffected by CPU load
* I/O load has a significant effect
* Use nice -n -20 to reduce the variance
For a CPU bound, non-VFP, L1 bound, 5 s long program:
* The variation coefficient is < 0.01 % so we can reliably measure
0.1 % changes
* The accuracy is around 50 us
I've changed eembc-linaro and will change denbench-linaro next. I
recommend anyone else measuring time on core based benchmarks to do
the same.
-- Michael
The Linaro Power Management Working Group has created a Launchpad project to
develop functional test suite for the power management blocks on arm:
* cpuidle
* cpufreq
* cpu hotplug
* sched_mc
This test suite would allow to quickly spot configuration errors and
regressions in existing
functionality on automated daily builds. It will be continually enhanced
to incorporate new frameworks, stress-test existing ones and eventually add
energy measurements.
The project can be found at: https://launchpad.net/linaro-pm-qa
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Hello,
Some time passed since last update on Gerrit deployment, that's
because work on complete AOSP mirroring to out tree took longer than
expected. All in all, following was done:
Revamped branching in our toolchain/* components, freed room for
upstream branches, mirrored them.
Mirrored AOSP kernel components. That was something I was putting
off until latest, knowing that it would bring enough burden, like
increasing storage space, increasing sync time, etc. Until last I wasn't
sure if they should mirrored, but something which turned scale is
recent talk about possibility to provide image for consumer phones from
Google (for which we may want to hack kernels as provided by AOSP).
Other point was just having complete AOSP mirror, and writing that
question off forever, freeing space for other work. So, I proceeded
with doing it, which soon led to OutOfMemory in Gerrit, so it's
probably good that it got uncovered during deployment, than later.
Thanks to IS, memory and Gerrit size were increased, and kernel imports
finished successfully.
That means that we have complete mirror of upstream AOSP tree, and out
tree is a proper superset of AOSP. The only workitem left is setting up
automated upstream syncing via cron (so far I've been doing this
manually), and we have nice tree set up with upstream at our fingertips
(without having availability issues during builds, etc.), and at the
same time, have all freedom to do any stuff on top of it (branching,
tagging, etc.)
I also updated Linaro Gerrit howto:
https://wiki.linaro.org/Platform/Android/Gerrit , which now should have
all info to have one started quickly with Gerrit, and cover all aspects
of Gerrit setup (like upstream mirroring and permission settings). I'd
appreciate review of that and letting me know if something is missing
there.
Finally few points we can continue with to elaborate our usage of
Gerrit:
1. Set up branch policy (naming, etc.) and enforce it on Gerrit level.
This may require revamping branching in other toolchain/* components
(upstreamed not from AOSP), but in the end we'll get really robust
development setup.
2. Turn off review bypass option which was available during transition
process. I guess Android team if comfortable by now with new process
(there're more than 80 patches passed thru review by now!), so once
11.08 release is out, it would be good time to do that.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
From: Linus Walleij <linus.walleij(a)linaro.org>
This is the sixth iteration of the controller subsystem, most
changes are described in the first patch, copied here for reference:
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
Linus Walleij (4):
drivers: create a pin control subsystem v6
pinmux: add a driver for the U300 pinmux
amba: request muxing for PrimeCell devices
mach-u300: activate pinmux driver, delete old padmux driver
Documentation/ABI/testing/sysfs-class-pinmux | 11 +
Documentation/pinctrl.txt | 876 ++++++++++++++++++++++++
MAINTAINERS | 5 +
arch/arm/mach-u300/Kconfig | 2 +
arch/arm/mach-u300/Makefile | 2 +-
arch/arm/mach-u300/core.c | 38 +-
arch/arm/mach-u300/include/mach/syscon.h | 136 ----
arch/arm/mach-u300/mmc.c | 16 -
arch/arm/mach-u300/padmux.c | 367 ----------
arch/arm/mach-u300/padmux.h | 39 --
arch/arm/mach-u300/regulator.c | 16 +
arch/arm/mach-u300/spi.c | 20 -
drivers/Kconfig | 4 +
drivers/Makefile | 2 +
drivers/amba/bus.c | 49 ++-
drivers/pinctrl/Kconfig | 36 +
drivers/pinctrl/Makefile | 7 +
drivers/pinctrl/core.c | 599 +++++++++++++++++
drivers/pinctrl/core.h | 24 +
drivers/pinctrl/pinmux-u300.c | 931 ++++++++++++++++++++++++++
drivers/pinctrl/pinmux-u300.h | 141 ++++
drivers/pinctrl/pinmux.c | 822 +++++++++++++++++++++++
drivers/pinctrl/pinmux.h | 4 +
include/linux/amba/bus.h | 2 +
include/linux/pinctrl/machine.h | 73 ++
include/linux/pinctrl/pinctrl.h | 172 +++++
include/linux/pinctrl/pinmux.h | 124 ++++
27 files changed, 3935 insertions(+), 583 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux
create mode 100644 Documentation/pinctrl.txt
delete mode 100644 arch/arm/mach-u300/padmux.c
delete mode 100644 arch/arm/mach-u300/padmux.h
create mode 100644 drivers/pinctrl/Kconfig
create mode 100644 drivers/pinctrl/Makefile
create mode 100644 drivers/pinctrl/core.c
create mode 100644 drivers/pinctrl/core.h
create mode 100644 drivers/pinctrl/pinmux-u300.c
create mode 100644 drivers/pinctrl/pinmux-u300.h
create mode 100644 drivers/pinctrl/pinmux.c
create mode 100644 drivers/pinctrl/pinmux.h
create mode 100644 include/linux/pinctrl/machine.h
create mode 100644 include/linux/pinctrl/pinctrl.h
create mode 100644 include/linux/pinctrl/pinmux.h
--
1.7.3.2
What we want to do for the next linaro release 11.09 is have working
USB wifi support out of the box on beagle/beagle xm with the developer
image.
Tho you won't have to twist my arm hard at all to include BT in that
goal as well Tony :-)
We like to keep the developer image as small as possible so the fun
part is keeping this to the minimal number of packages to make it
work.
For wifi I BELIEVE we just need to add wireless-tools.
So here's what I'd like you to do.
Grab the developer rootfs -
http://snapshots.linaro.org/11.05-daily/linaro-developer/20110831/0/images/…
grab the omap3 hwpack -
http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/omap3/20110831/0/ima…
Install to sd with linaro-media-create.
If you can apt-get install wireless-tools and see if that's enough to
get your wifi working. If not what else did you need?
For bluetooth, same Q if you want to have that as a goal as well. It's optional.
Either way I don't have a wifi USB device or BT so your help is essential!
Thanks!
Tom
On Wed, Aug 31, 2011 at 12:26 PM, Tony Mansson <tony.mansson(a)linaro.org> wrote:
> Tom,
>
> sure, I have an XM and a USB Bluetooth. I guess I can get a USB WiFi
> if I have to. But I agree that drivers can be an obstacle. What I
> don't have is a lot of spare time :-)
>
> But keep me in the loop.
>
> /Tony
>
> On 31 August 2011 17:52, Tom Gall <tom.gall(a)linaro.org> wrote:
>> On Wed, Aug 31, 2011 at 10:51 AM, Robert Nelson <robertcnelson(a)gmail.com> wrote:
>>> On Wed, Aug 31, 2011 at 10:47 AM, Tom Gall <tom.gall(a)linaro.org> wrote:
>>>> As the subject says. Looking for someone with either a beagle or
>>>> beagle xm board and has a USB Wifi. We'd like to knock off a bug. Your
>>>> help would be greatly appreciated. Please reply to me directly.
>>>> Thanks!
>>>
>>> Hi Tom,
>>>
>>> Is there a specific USB WiFi chipset your targeting, or just working
>>> WiFi in general?
>>
>> WiFi in general. In short we'd like to extend WiFi support into our
>> developer image.
>>
>>> Regards,
>>>
>>> --
>>> Robert Nelson
>>> http://www.rcn-ee.com/
>>>
>>
>>
>>
>> --
>> Regards,
>> Tom
>>
>> "We want great men who, when fortune frowns will not be discouraged."
>> - Colonel Henry Knox
>> Linaro.org │ Open source software for ARM SoCs
>> w) tom.gall att linaro.org
>> w) tom_gall att vnet.ibm.com
>> h) tom_gall att mac.com
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev(a)lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>>
>
--
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hi there.
The validation team has a new edge website,
http://edge.validation.linaro.org/ that reflects the development trunk
of all of our components. This site can be used to check latest
development effort, test bug fixes and, to some degree, use new features.
This website mimics the concept of now-defunct edge.launchpad.net. That
is, it allows for new code to run on top of the production database.
This has important ramifications:
1) Unsafe code could cause data loss
2) New features that depend on database schema modifications cannot be
tested this way.
3) Non-website features such as dispatcher and part of the scheduler
cannot be tested this way.
For addressing those we will soon deploy staging.validation.linaro.org
that works on a periodic snapshot of the production database.
I will be posting an update with instructions on how to replicate this
setup if necessary and details about the periodic automatic roll
out/upgrade procedure.
Thanks
Zygmunt Krynicki
Dear ARM fans,
Linaro Developer Platform team organises every week (Wednesday 14:00 -
18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to
fix userspace portability issues across the board. The list of bugs
being worked on
is at launchpad:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby…
Interested in making the software in Ubuntu run better on ARM? Join us on
the #linaro channel on irc.linaro.org (aka freenode) today!
Cheers,
Riku
Key Points for wider discussion
===============================
11.08 Release is out of the door.
11.09 BPs are here: https://launchpad.net/linaro-android/+milestone/11.09
Team Highlights
===============================
igloocommunity (Snowball) bugs can now be linked to from launchpad.
Lots of testing took place in the release week.
Miscellaneous
===============================
Imminent activities in management and administration:
- Guidelines for Gerrit review work.
- Get boards for the Automated testing.
- Join forces with Validation to assert Automated testing can be rolled out.
- Assert that toolchain and product release schedules are not colliding.
bhoj has started. He will be TI PoC and is based in Bangalore.
fgiff will be on vacation 2011-09-26 to 2011-10-07
