Hi there. We'd like to run a Fast Model in the validation lab for KVM
testing. Is there a blueprint for this? What's the status?
Paul and I discussed a rough plan a few months ago. It was along the lines of:
* A x86 machine as the Fast Model host
* An emulated vexpress-a15 as the KVM host
* A vexpress-a15 as the KVM guest
* LAVA treats the Fast Model as a board
* Jobs are spawned into the LAVA scheduler
* Once the KVM host is running, everything else is toolchain specific
and done via shell scripts
The dispatcher would:
* Grab the hwpack
* Grab the nano rootfs
* Build the rootfs with separate kernel, initrd, and dtb using
linaro-media-create
* Start the Fast Model with the boot wrapper, kernel, and rootfs
* Use the console to run the test script
There's more information on the steps required at:
https://wiki.linaro.org/MichaelHope/Sandbox/KVMUseCase
-- Michael
== GCC ==
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to Linaro GCC 4.7 and 4.6.
* Completed design of new optimization sub-pass to improve
re-association of plus/minus chains for types with undefined
overflow (to improve end-of-loop value computation);
started implementation.
* Investigated GCC PR target/44141.
* Started investigation of TSVC vectorizer test kernels.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
* Linaro GCC
Did the merges from upstream ahead of the Linaro releases next week.
Unfortunately, with the Linaro office move the test system is running
slowly, and it took a long while for Uli's concerns about the 4.7 merge
to be confirmed, so this might cause a bit of delay while I remerge, and
retest.
Begun looking at a solution for GCC Bugzilla pr53189. I've rewritten the
anddi3, iordi3 and xordi3 patterns to avoid the problems when NEON is
not available, and also improved the situation when NEON is enabled.
There are still a few kinks that need to be ironed out with poorly
optimized extend-and-operate sequences, and then I'm done, I hope.
* Other
Public holiday on Monday.
Summary:
* arm-linux-gnueabihf and multilib support for linaro toolchain.
Details:
1. Make arm-linux-gnueabihf and multilib work together for linaro toolchain
* Tuning the include and link path and order.
* The build requires a sysroot with both soft and hard float support
(Refer precise-sysroot-armhf-r0c.tar.bz2 at
http://people.linaro.org/~michaelh/incoming/). With the sysroot, a
reference multilib toolchain build is at
http://people.linaro.org/~zhenqiangchen/
* Update the Makefiles in tests to support armv4t build.
* Setup a pandaboard and run some tests.
Plans:
* Investigate other code size regressions in 4.7.
* Prepare for linaro binary toolchain 2012.05 release.
Best regards!
-Zhenqiang
<Short week given bank holiday>
Progress
* Committed the VFP addressing modes patch.
* Investigated PR48941 patch a bit more - looks like an issue with the
register allocator around vzip and vuzp patterns and not sure what the
easiest way of sorting this really is. I wonder if we should be
looking at some of the issues around secondary reloads or friends for
this particular patch - we generate too many vmov's for my liking and
with more complex code this ends up as spills !
* Backported gnu_unique_objects patch. Need approval to commit in Linaro tree.
Plans
* Backport VFP addressing patch to Linaro tree.
* Finish smin-umin idiom patch in the backend.
* smin - umin idiom patch in middle-end - investigate further.
Absences:
* May 28- June 3 : Away to Linaro Connect.
(short week, bank holiday)
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04 || 2012-02-01 ||
== cp15-rework ==
* various fixes following Rusty's review
* attempted to fix an issue where we would leak the hashtable
every time a new thread is created in linux-user mode. This
has run into the problem that qemu's current "copy this cpu
object" function has no place to insert cpu-specific code to
handle state which can't be simply shallow copied. This might
introduce a dependency on some object model rework, though
I'd prefer to avoid that.
== other ==
* put together and tested qemu-linaro 2012.05 prerelease tarball
* usual upstream review: couple of ARM fixes sent in for 1.1
-- PMM
Hi,
OpenEmbedded-Core/meta-linaro:
* finished script to automate the checkout, build and test of
oe-core+meta-linaro (denzil)
* currently supports GCC 4.6 based toolchains only
* pushed support for Linaro GCC 4.7 to meta-linaro/master
* backported support for GCC 4.7 based toolchains to the denzil branch
of meta-linaro
* when using GCC 4.7 against the oe-core release:
* Qt 4.8 fails to build (probably needs backporting a fix)
* sato images are booting but don't show the matchbox wm
Regards,
Ken
Hi Ken. I've checked in a rough script that builds OpenEmbedded
inside the cbuild Makefile-based auto builders.
To run it yourself:
* bzr branch lp:cbuild
* cd cbuild
* cp oecore.mk lib
* mkdir -p slaves/`hostname`
* cd slaves/`hostname`
* make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under
cbuild/lib. The steps are driven by steps.mk which use stamp files to
see what is finished and what needs running. The normal steps are
configure; build; install; testsuite; run. I've split the build and
similar steps into one per architecture and added a ping to the
scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each
one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level
build directory is $LBUILD (gcc-native/oecore). The variant build
directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant).
The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES
and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as
using the vexpress-a9 model. Use patch-% as the fallback and the
specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are
snapshotted on change:
* kwerner/meta-linaro
* openembedded-core/denzil
and end up at:
http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script
uses my normal tactics:
* Everything over HTTP
* Use a in-network proxy, set in ~/.wgetrc
* Pull from a mirror first or only
(http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/ > ~/.wgetrc.
I've seeded the mirror. We should keep track of any extras needed
such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk.
Might speed the build and not wear the build disk out.
-- Michael
Hi,
GDB for Android:
* Reviewed Carlos O'Donell response to my message in lsb-discuss to think
about the pros and cons of the approaches he mentioned, did some
investigation. Maybe the ABI-tag is not needed, at least for debugging
purposes (there may be other uses).
* Wrote patch which detects an Android app by looking at the ELF
interpreter field in the binary.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
