Seabright Technology

Zhenqiang and I have been working on pre-built version of Linaro GCC to make cross compiling your apps for ARM easier.  The first version is out and up at https://launchpad.net/linaro-toolchain-binaries.  Here’s the announcement:

The Linaro Toolchain Working Group is pleased to announce the release of the Linaro Toolchain Binaries, a pre-built version of Linaro GCC and Linaro GDB that runs on generic Linux or Windows and targets the glibc Linaro Evaluation Build.

This is the first release. Releases will be made each month shortly after the corresponding source release.

Uses include:

• Cross compiling ARM applications from your laptop
• Remote debugging
• Build the Linux kernel for your board

What’s included:

• Linaro GCC 2012.01
• Linaro GDB 2011.12
• A statically linked gdbserver
• A system root
• Manuals under share/doc/

The system root contains the basic header files and libraries to link
your programs against.

The Linux version is supported on Ubuntu 10.04.3 and 11.10, Debian 6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation 5.7 and later, and should run on any Linux Standard Base 3.0 compatible distribution. Please see the README about running on x86_64 hosts.

The Windows version is supported on Windows XP Pro SP3, Windows Vista Business SP2, and Windows 7 Pro SP1.

I recently gave a a presentation on benchmarking techniques that covered our method, measuring, the statistics, and some future directions like STM. A copy is available under people.linaro.org/~michaelh/presentations

The notes version is a bit more readable.

Grab the original from Launchpad:
 bzr branch lp:~michaelh1/+junk/benchmarking-techniques

I did a short presentation on NEON intrinsics at the recent Linaro Connect in Cambridge.

Click here to grab a PDF version. The original ODP version complete with animations and notes is in source control. Try:
bzr branch lp:~michaelh1/+junk/intrinsics-demo

The presentation is nice and technical and covers what NEON intrinsics are, what the types and functions look like, and a colour space conversion example comparing plain C, hand written assembly, and the (more readable? more maintainable? faster?) intrinsics version.

I run a build farm for the toolchain group here at Linaro. The boards get a bit busy during release week:

The ursas are bootstrapping and testing three different configurations of the candidate GCC. The leos are checking the A9 build by rebuilding 22 essential packages from Ubuntu. The oorts are x86 cloud instances doing much the same.

Busy busy. It’ll be good to get these out and LAVAised once the validation farm comes online.

hurry.filesize does exactly what it says on the box and just what I needed – convert a number in bytes to a human readable string like ’30.4 GB’. Nice.

Toolchain has four PandaBoards that are used for building GCC, GDB, and other interesting programs. Here’s a graph of how busy they are:

The green line is how many boards are currently running jobs. The blue line is how many jobs are queued up. The spike at day 3 is the end-of-week build of the upstream branches. The drop to three boards at day 7 is me reserving one for benchmarking. The spike at day 8 is the start of our release week where many commits and the final tarballs are built and tested.

All boards were busy for seven days out of eight. I think I might need a few more in the pool…

I’m working on an equivalent to the Android toolchain build which is easier to develop against and uses the native libraries shipped with Ubuntu. Part of that involves updating a few packages and getting them into the cloud based build farm. Launchpad’s private package archive is a great way of getting these built for a range of architectures and then sharing them about, but I’d like to test the packing before firing them off. That’s where pbuilder comes in.

Create a Natty based pbuilder:

sudo pbuilder create \
--distribution natty \
--components "main universe" \
--mirror http://nz.archive.ubuntu.com/ubuntu/ \
--http-proxy http://proxy:8123/

(Pull from NZ, use my local proxy)

Create the source package:

dpkg-buildpackage -S

Build inside pbuilder:

sudo pbuilder build binutils*ppa1.dsc

Push the build up to the ppa:

dput ppa:linaro-toolchain-dev/build-deps binutils*ppa1_source.changes

And wait for it to appear!.

We do a lot of GCC builds in the Toolchain Working Group. The x86_64 and i686 builds were beginning to overwhelm the build farm so I thought I’d have a play with the cloud and shifted them out to Amazon EC2. The x86_64 builds are nice and fast – a c1.xlarge instance bootstraps C, C++, and Fortran in 38 minutes and tests in 34.

The i686 builds were problematic. A Natty instance store backed c1.medium instance would bootstrap fine but then show random failures when running the testsuite. Using Natty EBS backed AMI and running the testsuite sequentially cleared up the problem, but unfortunately takes twice as long to run.

For reference, the c1.medium bootstraps in 64 minutes and tests in 2:48.

The Free Electrons guys have posted their videos of the 2011 Embedded Linux Conference at http://free-electrons.com/blog/elc-2011-videos/.

There was quite a Linaro contingent there.

We’re currently doing the next six months worth of planning here at Linaro. I wanted a simple Gantt chart to show when a task is expected to start and finish and found a nice way of doing it using a LibreOffice stacked bar chart.

The trick is to make the first bar invisible and use it as an offset. Start with a table like this:

Select all of the data, then select Insert | Chart.... Select ‘Bar’ then the stacked bar chart. Click finish and you’ll see something like this:

Note how the rows are in an unfortunate bottom to top order. Double click on the blue part of any bar to bring up the Data Series dialog. Click on the Area tab, set the Fill to None, and you’ll get this:

You can use extra columns to get extra colours. Here’s the final toolchain timings chart:

The spreadsheet this came from is available at:
bzr branch lp:~linaro-toolchain-wg/planning-1111