I unpacked our minimal release image and ran an xdiskusage on it,
mostly to see what we're shipping -- and I was surprised to see that a
fourth of the image is actually apt package caches and lists. Can we
put into the image generation script something to strip them out before
generating the image?
The untarring also suggests a number of places where we could further
trim the image, some of which are probably pretty hard to do:
* stripping /usr/share/doc out (but everybody knew that)
* dropping charmaps, zones and locale info that will never really be
* stripping out modules for devices that won't ever be on
this ARM device
* stripping out firmware for peripherals that won't ever be on this
I've included the xdiskusage output so you can see what I mean. And good
job on the release!
Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kikoLinaro.org | [+55 16] 9112 6430 | http://async.com.br/~kiko
On Wed, 11 Aug 2010, Will Deacon wrote:
> Hi Nicolas,
> > The Linaro freeze is imminent, and at that point a stable branch that
> > won't be rebased anymore will be forked. The stable branch should only
> > see bug fixes and no new features. Therefore I'd like to know if there
> > is anything that should be added or removed from this tree before the
> > freeze is in place. Please tell me ASAP.
> The only thing I can think of from my end is the hardware breakpoint patches
> I have:
> I've not merged these into my Linaro branch because I'm not happy with the
> amount of testing they've received [it's a bit of a catch 22 because one
> good way to get them tested is to merge them!].
My criteria would be:
1) Could their addition break something else even when not used?
If there is no risk for regression then we could as well just include
them and add fixes later if need be.
2) Is there some ABI implied with gdb or the like?
If there are ABI issues then I'd prefer having the assurance that it
won't change by the time this gets merged into the mainline kernel.
I had a quick go at benchmarking the Linaro GCC compiler and was
presently surprised. The workload was decoding 10 s of h.264 video
using ffmpeg with assembly optimisations disabled. This gives the
compiler a good workout.
Compared to FSF GCC 4.4.4, Linaro GCC 4.4 is 6 % faster, FSF GCC 4.5.0
is 12 % faster, and Linaro GCC 4.5 is 24 % faster.
Now this is with a sample size of one so the results are not
statistically valid, and I haven't told you how to reproduce it so
they're not scientifically valid, but the numbers are pleasing none
To stick to good open-source development standards I'd like to announce
Launch Control code reviews on the mailing list.
This is just a public ping of the following merge request:
Anyone interested in Launch Control development is welcome to review
this and post comments on the launchpad merge request page (they get
forwarded as emails to all participants).
Zygmunt Bazyli Krynicki <zygmunt.krynicki(a)linaro.org>
PowerTOP is a tool used to provide information related to power
consumption, from various sources, into one screen. One of the issues
with PowerTOP is that the number of C and P states are hardcoded and
thus it doesn't provide complete information on systems which may have
more states than the hardcoded ones. Thus, though it works well on
intel platforms, it may not on some of the ARM boards.
Changes being suggested:
These are couple of simple patches which try to make PowerTOP generic
enough to run on almost any platform, which is plugged into the
cpufreq and cpuidle framework. Thus the number of C and P states will
no longer be hardcoded (though, the MAX values will be, to allocate
enough memory for data structures). Most of the changes required is to
make the display be aware of the ACTUAL number of these states and not
just depend on some hard coded values.
Where to get the source and patches:
You can get it from the git repo located at
The "master" branch has the PowerTOP code in sync with latest upstream
powertop git tree. The "linaro" branch has my patches, which need
testing. So, once you clone the tree, please do not forget to checkout
the "linaro" branch (git checkout -b linaro remotes/origin/linaro)!
Note: If you had cloned it before, please clone a fresh tree, since I
have re-written the history for "linaro" branch, to get patches in
shape for upstream submission. Something, which I know should be
avoided in future.
What to review:
Once you checkout the "linaro" branch, as suggested above. You can
review the two patches with commit id "09049b42e3" and "783a3e6bbe".
What to test:
Some of the things which could be tested is,
o Compile and test on any ARM board that you may have. You can also
test on any x86 / x86_64 systems, to check if nothing has been broken.
o Compare the output from "master" and "linaro" branches ("-d" dump
option may help, if you wish to take a diff)
o Check if the number of C states is correct
o Check if the number of P states is correct
o Check if the % values makes sense (say, if total doesn't add to 100!
Or, if its a very huge value  ).
o If number of Wakeups-per-second  looks reasonable.
o Top causes for wakeups is shown properly
o Suggestions are shown properly. Some of the suggestions may show a
hot key on the status bar (at bottom).
 There is a known issue of %age values and Wakeups-per-sec number
being shown very high (in the order of thousands), if some key is hit
(say, 'r' to refresh or any other key). This problem can be seen in
"master" branch (upstream) too, and hence is not introduced by the new
patches. Since the goal of these patches is different, I haven't
addressed this issue here.
Note: Thanks a ton to people who tested my initial patches and
provided their valuable feedback.
The minutes of the weekly call fresh-off-the-oven can be found at:
Linaro: Amit Kucheria, Amit Arora, Vishwanath Sripathy, Yong Shen
ARM: Srinivas Kalaga, Robin Randhawa
Action Items from this Meeting
* Action: Robin and Srinivas to send mail to team, to target the
ftrace patches for upstream.
* Action: Amit K to send email regarding power aware scheduling by
Intel (CONFIG_SCHED_MC & CONFIG_SCHED_SMT ?) Yes!
* ACTION: Yong Shen to test Amit Arora's powertop patches and
* ACTION: Yong Shen to investigate plugging in cpufreq framework
for freescale boards
* ACTION: Amit Arora to creat a new wiki page for instructions on
how to setup your own git repo on git.linaro.org
* ACTION: Amit K to talk to jeremy about power domain framework
* ACTION: Amit Arora and Yong to discuss about reporting sensor
information (hwmon, or some other source for ARM?)
Action Items from Previous Meeting
* ACTIVE (Immediate):
o ACTION: Bobby to investigate android contraints (e.g.
display keep-alive): CLOSED
+ Bobby sent a mail. Considering closed.
o ACTION: Srinivas to add ftrace item to task list and send
patches to linaro: CLOSED
+ Srinivas has emailed the patches to team. Needed to
get time-stamps when system is entering low power state with various
o ACTION: Vishwa to create a new blue print for the
instrumentation of cpuidle related work: CLOSED
+ Blue print created and assigned to Vishwa.
o ACTION: Amit Arora to create tarballs of his current work
and share it internally for testing: CLOSED
+ considered done, git tree now available on git.linaro.org
o ACTION: Amit Kucheria and Vishwa to get inputs from
community on the issues related to CPUIDLE governor: POSTPONED until
* ACTIVE (Long Term) :
o ACTION: Srinivas to provide details of where he believes
userspace - kernel interaction is required. (low prio)
o ACTION: Bobby to check on multi-core boards availability
o ACTION: ARM to discuss giving out internal Eclipse based
tool (similar to powertop) (no ETA as of now)
* DORMANT :
o ACTION: ARM to share internal instrumentation flow (BAB:
we might also align with Linaro on workload discussions)
+ Might take couple of months
* ftrace patches part of larger tool work inside ARM, perhaps the
ftrace patch doesn't need to wait for the entire tool and can be sent
* power aware scheduling using perf counters, cache misses/hits,
o ties into instrumentation work for cpuidle being done by Vishwa
* Discussion regarding power domain framework
o Similar to clock framework
o Does SRF replacement handle it? No, according to Vishwa.
* displaying sensors information - is it duplicating work done by
o figure out what drivers are using hwmon
o perhaps it would make sense to use the lm-sensor library
(is there any?) to grab this info?
* API to read performance counters
o arch/arm/kernel/pmu.h perf_event.c
o No documentation? (Perhaps we should provide docs?)
...are available here:
A copy follows, along with activity reports for the different members.
• Name Email IRC Nick
Yao Qi yao.qi(a)linaro.org yao
Ulrich Weigand ulrich.weigand(a)linaro.org uweigand
Scott Bambrough scott.bambrough(a)linaro.org scottb
Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw
Peter Maydell peter.maydell(a)linaro.org pm215
Michael Hope michael.hope(a)linaro.org michaelh
Marcin Juszkiewicz marcin.juszkiewicz(a)linaro.org hrw
Loïc Minier loic.minier(a)linaro.org lool
Julian Brown julian(a)codesourcery.com jbrown
Dave Martin dave.martin(a)linaro.org dmart
Chung-Lin Tang cltang(a)codesourcery.com cltang
Andrew Stubbs andrew.stubbs(a)linaro.org ams
• Review action items from last meeting
• New public call-in number: code 263 441 7169
• Release status
□ 4.4 at http://ex.seabright.co.nz/build/gcc-linaro-4.4-2010.08-0/
□ 4.5 at http://ex.seabright.co.nz/build/gcc-linaro-4.5-2010.08-0/
□ Ubuntu toolchain would prefer 4.5.1
• Next focus
□ Merging patches upstream
□ Prioritising GDB features
• Future focus
□ Emphasise performance, neutral on correctness
□ Topics to investigate
☆ Upstream research topics
□ Topics for UDS
Initial delivery of Linaro GCC 4.4 ams
Cross Compiler Packages hrw
Action Items from this Meeting
Action Items from Previous Meeting
• DONE: Michael to organise and spread next Monday's call in number
• ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5
• DONE: 500524 Ulrich to backport to Linaro 4.4
• DONE: Test failures: Michael to build FSF 4.4.4 as a baseline
• DONE: Test failures: Michael to compare FSF and Linaro GCC failures
• DONE: Test failures: All Linaro GCC failures to be ticketed
• DONE: LTO check on ARM: Michael to reproduce. check-lto fails with no
• DONE: Ulrich to write up known GDB work
• DONE: 598147: Michael to reproduce the test failures
• DONE: 398403: Andrew to reproduce on his IGEP board (has more RAM)
• DONE: Michael to make sure merge requests are present for work that has
• Release status
□ Talked about the upcoming 2010.08 release
□ Andrew has posted tarballs which Michael has grabbed and built
□ Andrew is cross-testing
• Discussed 4.5.1
□ 4.5.1 came out, depending on where you look, 11, 8, or two days ago
□ Rolling in 4.5.1 and the Firefox exposed alignment bug would have more
□ Discussed time based vs feature based releases and a pragmatic middle
□ Discussed releasing 4.5.0 based now vs 4.5.1 at next months release vs
□ Decided to delay the Linaro 4.5 release until at most 2010-08-17
□ Roll in 4.5.1 and the Firefox fix
□ Gives something more useful to Ubuntu and others
□ ACTION: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17
• Discussed what goes in next month
□ Richard wants the sync primitives fixes
□ CSL is still merging their patchset
• Discussed what can be done in the future
□ Please start thinking of topics for UDS
□ Backporting the new costing infrastructure (Richard)
☆ Works by changing how costs are done and making them more generic
☆ Backend provides options for a certain segment
☆ Cost of an option is target dependent
☆ Removes a lot of hard-coded values for particular architectures
☆ Good for core-next
☆ Infrastructure matches trunk
☆ Might pull in ldm changes
□ Richard's wishlist
☆ v6 SIMD, v5 (limited)
□ Conditional instructions
☆ Some are best done at the expand phase where tree goes to RTL
☆ Not on Roger' slist
☆ Check on possible gains
□ NEON intrinsics
☆ Don't generate very good code at the moment due to load/stores
☆ Might need internal intrinsics to compose these out of
☆ Developers currently use straight asm, perhaps out of personal
☆ Intrinsics aren't well documented/known
☆ Worthwhile as people coming from RVDS and using intrinsics will see
☆ Ulrich sent through his list
☆ To categorise into features and fixes
☆ ACTION: Ulrich to ticket items
☆ Work on critical fixes first
☆ Yao, Ulrich to work on list
☆ ACTION: Michael to understand whiteboards as a way of organising
Next meeting is a standup meeting on 2010-08-11 on the public code.
== Linaro GCC 4.4 ==
* Reviewed various merge requests.
* Created and tested GCC Linaro 4.4-2010.08-0 release tarball.
== Linaro GCC 4.5 ==
* Continued pushing CS patches to Linaro GCC 4.5. I've done quite a
lot of these this week, but I've had to omit some patches that caused
* Created and tested GCC Linaro 4.5-2010.08-0 release tarball.
== Other ==
* Set up EEMBC for use with Linaro GCC so Chung-Lin can compare
hard-float and soft-float ABIs.
* Attended the monthly CS/Linaro sync call.
== Linaro GCC 4.4 bug fix ==
* LP:602190 & LP:602285
They are caused by a patch for performance improvement of generated
code. Team suggests keep this patch, and fix test case a little bit
to fix failures.
Fix to LP:602285 is committed and merged to linaro 4.4.
Thinking about how to fix LP:602190 from test case side. An option
to force to turn 'cunroll' off is helpful.
* LP:612011 & GCC PR45094
Update test case pr45094.c from a compilation test to an execute
test. Sent to gcc-patches again. Waiting for ARM backend
Merge this patch to linaro 4.4 first, because of release. Plan to
backport to linaro gcc 4.5 once patch is approved by upstreams.
* LP:612405 & LP:612406
Fix them by changing ARM target triplet from "arm-*-*" to
"arm*-*-*", which is more general.
Merged to linaro gcc 4.4.
Create a patch against FSF GCC trunk to fix this in other test
Same bug was reported in GCC Bugz PR41501/PR34999, which have been
fixed on FSF GCC 4.5.0. No plan to backport to FSF 4.4.x.
Leave this bug as Won't Fix on linaro gcc 4.4 and Fix Released on
linaro gcc 4.5.
Can't reproduce it on arm-none-linux-gnueabi. Latest result shows
obj-c++.dg/bitfield* only failes on x86-64.
* LP:602168 g++.dg/eh/pr42859.C test failure
Analyze this bug a little bit, and my initial result is that two
BBs in exception catch are *not* marked as UNREACHABLE in linaro 4.4,
while these two BBs are UNREACHABLE FSF GCC 4.4 trunk.
== This Week ==
* Ping ARM backend maintainer for my patch to GCC PR45094.
* Submit my patch on ARM target triplet in gcc patches.
* Update status of LP bugs. Mark them as Fix Released if failure go
away in gcc-linaro-4.4-2010.08-0.
* Other linaro 4.4 bugs to look or other new work to do.
Wrap up LP:602190.
Analyze deeply on LP:602168/LP:602174.
Amber: waiting final ARM legal OK for qemu contributions
Green: Completed all the linaro new-starter admin tasks
Milestones: none as yet
- Miscellaneous setup/configure/getting started.
- got qemu to boot linaro alpha-2 with random ubuntu versatile kernel
- I have a set up that lets me rebuild kernels now
- maemo-qemu supports beagle but the stock linaro alpha 3 takes a
div-by-zero exception and panics on startup
- flesh out some of the blueprints assigned to me
- investigate the div-by-zero panic
- find out the easiest way to replace the kernel in the shipped
alpha 3 with one I've compiled
- make sure virtio is enabled in kernel and try to get it working
== GCC ==
* Prepared Linaro GCC 4.5 backport for bug #604874 (Firefox fails to
* Prepared Linaro GCC 4.4 backport for bug #500525 (bootstrap failure in
* Investigated bug #600209 (getfem++ test failures)
* Investigated bug #602168 (g++.dg/eh/pr42859.C failure)
* Investigated bug #506538 (GENERAL_REGS spill failure)
* Determined root cause of bug #608125 (gnat build failure)
* Determined root cause of Debian bug #591075 (glib2.0 segfault on ARM /
== GDB ==
* Started planning future GDB feature / bugfix work
== Miscellaneous ==
* Converted multiarch toolchain implications document to Wiki page
== libffi VFP hard-float support ==
Mostly finished and doing testing. Using libffi's testsuite, currently
has three regressions, two of them related to testing of variadic
functions, which are pretty unsolvable due to AAPCS' rule of reverting
to the base calling convention for all variadic functions (the libffi
code currently has no way of detecting variadic function type from the
user, so cannot correctly do this ABI revert). May solve by marking
the testcases to be skipped under -mfloat-abi=hard. Will work on a few
code optimizations before trying to submit it upstream.
== Other ==
Looking at some Linaro GCC bugs.