All,
for those of you that are here, welcome (especially any newbies),
hope you have a good week! For those of you not here, you can join
in as all of the sessions are streamed. You can also ask questions via
IRC. A good link to the Linaro sessions is here:
http://summit.linaro.org/uds-o/
Dave
--
David Rusling, CTO
http://www.linaro.org
Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH
Hello Android team,
I was working on making Android toolchain buildable using Android build
service, and finally I was able to do successful and reproducible
builds - of AOSP pristine bare-matal toolchain so far
(https://android-build.linaro.org/builds/~pfalcon/aosp-toolchain/).
There were few issues which needed to be investigated and resolved,
and which I would like to discuss here:
1. make -jN breakage
Android build service builds on EC2 XLARGE instances with 16
concurrent make jobs (-j16). This invariably leads to build failure
sooner or later (exact location depends on other options and maybe
non-deterministic at all). The failure is "error: Link tests are not
allowed after GCC_NO_EXECUTABLES." which somehow sends issue-hunting
the wrong trail (like sysroot issues, etc.) but after some experiments
I reduced this to exactly -j >1 being used, with -j1 it went past usual
failure points reliably.
2. Lack of DESTDIR support
There's standard GNU autotools variable "DESTDIR" to install package
into other directory besides $prefix. It is supported for gcc,
binutils, etc., but not for Android's own toolchain/build project. The
usual local-use trick is just to pass another prefix just for make
install target, and that's what toolchain/build's README suggests. My
only concern is "cleanroomness" of the results - suppose make install
suddenly wants to rebuild something (libtool used to have such habit),
then new prefix may be embedded into some executable, and then hit
beyond the usual usage pattern (like, with non-English locale). Still,
this is more a theoretical risk, which I as a build engineer should
note, but not something to much worry about.
3. libstdc++v3 build
toolchain/build's README says that the default is not to build
libstdc++v3 and it must be enabled explicitly. But in the current
master I found that not to be the case - it gets enabled by default.
And its build requires sysroot, so I had to disable it explicitly
for bare-metal build.
4. sysroot source
So, to build full-fledged toolchain, we need to supply sysroot.
What should be source of it? Android build service script I started
from extracts it from an official Android SDK release. Is that good
enough source? I guess we'd miss some non-released optimizations that
way (byteswap ARMv6 optimizations come to mind). Otherwise, what should
be used instead? Obvious choice is to build Android target images, then
build toolchain on that tree. But that would be too long and expensive.
Should we prepare and tar sysroot and provide it as extra build
artifact for Android target builds? Also, can there be any
machine-specificity, or it's for sure one generic sysroot for specific
Android version (with arch-specific things handled via #ifdef's)?
Of these 4, first 3 are upstream-related bugreports with known
workarounds. I wanted to write them down, but I'm not sure if more can
be done about them - if you think it would be useful to submit them as
bugs at lp/linaro-android (or directly to upstream?), I can do it.
Sysroot issue of course requires input/discussion - in mail or at some
LDS session.
Thanks,
Paul mailto:pmiscml@gmail.com
flag@omap:~$ dmesg | grep -A 1 L310
[ 0.219024] L310 cache controller enabled
[ 0.219055] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000,
Cache size: 1048576 B
^^^^^^^^^^^^^^
according to [1], that means Panda has a r3p0 L310 L2 controller.
[flag@newluxor linux-linaro-2.6.38]$ git show 885028e
commit 885028e4ba4caf49d565c96481e1a05220ecb517
Author: Srinidhi Kasagar <srinidhi.kasagar(a)stericsson.com>
Date: Thu Feb 17 07:03:51 2011 +0100
ARM: 6741/1: errata: pl310 cache sync operation may be faulty
The effect of cache sync operation is to drain the store buffer and
wait for all internal buffers to be empty. In normal conditions, store
buffer is able to merge the normal memory writes within its 32-byte
data buffers. Due to this erratum present in r3p0, the effect of cache
sync operation on the store buffer still remains when the operation
completes. This means that the store buffer is always asked to drain
and this prevents it from merging any further writes.
This can severely affect performance on the write traffic esp. on
Normal memory NC one.
The proposed workaround is to replace the normal offset of cache sync
operation(0x730) by another offset targeting an unmapped PL310
register 0x740.
Signed-off-by: srinidhi kasagar <srinidhi.kasagar(a)stericsson.com>
Acked-by: Linus Walleij <linus.walleij(a)stericsson.com>
Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Russell King <rmk+kernel(a)arm.linux.org.uk>
[1]:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0246d/Beibhh…
--
bye,
p.
Hi
I would like to ask about your display setups on work desks because
recent changes in pandaboard kernel moves me into 'lets buy another lcd'
direction...
Now I have two displays on my desk:
- 24" 1920x1080
- DVI port is main display of my desktop
- VGA port was used with some boards in past
- HDMI port was never used
- 20" 1680x1050
- DVI (with HDMI->DVI adapter) is main display of pandaboard
- VGA is secondary display of desktop or primary display of other
(rarely used) PC
But Pandaboard has two video outputs: DVI and HDMI. For most of time I
used HDMI output but it was with Ubuntu 11.04 kernel. Now I am testing
Linaro WIP kernel and it has working DVI output rather then HDMI one...
Switching ports on panda requires powering it off in order to not damage
it. Guessing which port works is not a way. Connecting panda HDMI to 24"
HDMI is also no solution cause this will leave me without display for my
desktop.
How you people solve that in other way then buying yet-another-lcd?
Last quasi-random question of the night: would reviving the kmemcheck
ARM port (that IIRC was hacked up a while back) be something useful, or
is it something that is too niche to be worth it? At the board's
request, I was looking across platform gaps and this feature was one of
the things that I found.
Thanks,
--
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko
I believe that some of these random application crashes claiming to be
out-of-memory have to do with the fact that swap is off by default.
Knowing that to be an issue from my experience with OpenEmbedded
I preemptively set
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
in /etc/sysctl.conf
However, this seems to have made the issue worse.
Has the meaning of these values changed between 2.6.36 and .39?
Or are the defaults used with Linaro / Ubuntu more appropriate for swapless
systems and those values don't need to be set?
I'd appreciate any advise on how to use the full memory of my system and not
get out-of-memory errors when I have 50%+ available memory.
AJ ONeal
Is there some sort of base kernel config that I can mixin to the
omap2plus_defconfig that will be likely to give me a more successful boot
with 2.6.39?
Please explain to me the process for creating such a defconfig.
Thanks,
AJ ONeal
I am hosting an introductory session on System Trace at the summit. TI's System Trace Module (STM) provides a common protocol for instrumentation messages across multiple cores and system level hardware profiling in complex SoCs. Attached is a whitepaper for background reading.
Looking forward to meeting you at the summit.
Regards,
Doug Deao
Texas Instruments