Linaro at work: porting, testing, and Android

Thursday, November 11th, 2010

Congratulations to Team Linaro on their first full release yesterday. For those not yet in the know, Linaro is a collaborative forum with dedicated engineers making sure that Linux rocks on ARM (and potentially other architectures). Staffed by a combination of Canonical and new Linaro engineers, together with secondees from the major ARM silicon vendors, it’s solving the problems of fragmentation in Linux across that ecosystem and reducing the time to market for ARM devices.

Linaro uses the same cadence as Ubuntu and we’re able to collaborate on the selection, integration and debugging of key components like the kernel, toolchain, X.org (still ;-)), and hundreds of small-but-important libraries and tools in between. Team Linaro was @UDS and it was very cool to see the extent to which their sessions drew attendance from the wider Ubuntu community – I think there’s a growing interest in efficient computing across the Ubuntu landscape.

The Linaro team is pleased to announce the release of Linaro 10.11.
10.11 is the first public release that brings together the huge amount
of engineering effort that has occurred within Linaro over the past 6
months. In addition to officially supporting the TI OMAP3 (Beagle
Board and Beagle Board XM) and ARM Versatile Express platforms, the
images have been tested and verified on a total of 7 different platforms
including TI OMAP4 Panda Board, IGEPv2, Freescale iMX51 and ST-E U8500.

The advances that have happened in this cycle are numerous but include a
completely rebuilt archive using GCC 4.4.4 and the latest ARM optimised
tool chain, the Linux kernel version 2.6.35, support for
cross-compiling, a new hardware pack way of building images, 3D
acceleration improvements, u-boot enhancements and initial device tree
support, a new QA tracking structure, the list goes on.

Android in the house

The road ahead looks even more interesting. For the next cycle, the Linaro team is going to build an Android environment on the same kernel and toolchain that we collaborate on with Ubuntu. For folks building devices, picking a board that’s part of the Linaro process means you’ll be able to get either an Ubuntu-style or Android-style core environment up and running at Day 1, which should reduce time to market for everyone.

If the Linaro team pulls this off, it will mean that Linaro provides an intersection point for the majority of the consumer electronics x86 and ARM ecosystem, regardless of the end OS. I’m sure over time we’ll find more groups that are interested in joining the process, and I see no reason why they couldn’t be accommodated in this cadence-driven model.

More players, more diversity in services

It was also good to see folks from Montavista and Mentor at Linaro@UDS this year. Whether the Linaro kernel and toolchain plug into their own distros, or they start to offer their services around the Linaro/Ubuntu/Android BSP’s, the result is a healthier ecosystem with fewer snags and gotchas for device makers.

One group asked me explicitly if Linaro was a Canonical show, and I was glad to say it isn’t. Canonical can’t possibly do everything that embedded Linux needs done, but our competence in cadence and release management makes us good custodians of a public project, which is what we do with Ubuntu itself. Participation and collaboration are at the heart, and they benefit from being partnered with a commitment to delivery and deadlines. We can’t do everything in a single cycle, but we can provide a roadmap for things like kernel defragmentation, the device-tree work, enablement of an ever-increasing cross-section of the ARM ecosystem, and transitions between versions of GCC or Python or X or even Wayland. So Canonical makes a good anchor, but Linaro has room for lots of other service-providers. Having multiple companies participate in Linaro means that the products we’re all shipping get better, faster.

Testing

The Linaro team is also going to focus on repeatable, rigorous testing of the core platform in the next cycle. That harmonises nicely with our growing focus on quality in Ubuntu, and the need for better quality and testing in open source in general. I’m interested to see what tools and results the Linaro team can produce in the next six months. Open source *can* be bulletproof, but it can also degrade in quality if we don’t put the right processes in place upstream and downstream, so this is a very welcome initiative.

Linaro: Accelerating Linux on ARM

Thursday, June 3rd, 2010

At our last UDS in Belgium it was notable how many people were interested in the ARM architecture. There have always been sessions at UDS about lightweight environments for the consumer electronics and embedded community, but this felt tangibly different. I saw questions being asked about ARM in server and cloud tracks, for example, and in desktop tracks. That’s new.

So I’m very excited at today’s announcement of Linaro, an initiative by the ARM partner ecosystem including Freescale, IBM, Samsung, ST-Ericsson and TI, to accelerate and unify the field of Linux on ARM. That is going to make it much easier for developers to target ARM generally, and build solutions that can work with the amazing diversity of ARM hardware that exists today.

The ARM platform has historically been superspecialized and hence fragmented – multiple different ARM-based CPU’s from multiple different ARM silicon partners all behaved differently enough that one needed to develop different software for each of them. Boot loaders, toolchains, kernels, drivers and middleware are all fragmented today, and of course there’s additional fragmentation associated with Android vs mainline on ARM, but Linaro will go a long way towards cleaning this up and making it possible to deliver a consistent platform experience across all of the major ARM hardware providers.

Having played with a prototype ARM netbook, I was amazed at how cool it felt. Even though it was just a prototype it was super-thin, and ran completely cool. It felt like a radical leap forward for the state of the art in netbooks. So I’m a fan of fanless computing, and can’t wait to get one off the shelf :-)

For product developers, the big benefit from Linaro will be reduced time to market and increased choice of hardware. If you can develop your software for “linux on ARM”, rather than a specific CPU, you can choose the right hardware for your project later in the development cycle, and reduce the time required for enablement of that hardware. Consumer electronics product development cycles should drop significantly as a result. That means that all of us get better gadgets, sooner, and great software can spread faster through the ecosystem.

Linaro is impressively open: www.linaro.org has details of open engineering summits, an open wiki, mailing lists etc. The teams behind the work are committed to upstreaming their output so it will appear in all the distributions, sooner or later. The images produced will all be royalty free. And we’re working closely with the Linaro team, so the cadence of the releases will be rigorous, with a six month cycle that enables Linaro to include all work that happens in Ubuntu in each release of Linaro. There isn’t a “whole new distribution”, because a lot of the work will happen upstream, and where bits are needed, they will be derived from Ubuntu and Debian, which is quite familiar to many developers.

The nature of the work seems to break down into four different areas.

First, there are teams focused on enabling specific new hardware from each of the participating vendors. Over time, we’ll see real convergence in the kernel used, with work like Grant Likely’s device tree forming the fabric by which differences can be accommodated in a unified kernel. As an aside, we think we can harness the same effort in Ubuntu on other architectures as well as ARM to solve many of the thorny problems in linux audio support.

Second, there are teams focused on the middleware which is common to all platforms: choosing APIs and ensuring that those are properly maintained and documented so that people can deliver any different user experience with best-of-breed open tools.

Third, there are teams focused on advancing the state of the art. For example, these teams might accelerate the evolution of the compiler technology, or the graphics subsystem, or provide new APIs for multitouch gestures, or geolocation. That work benefits the entire ecosystem equally.

And finally, there are teams aimed at providing out of the box “heads” for different user experiences. By “head” we mean a particular user experience, which might range from the minimalist (console, for developers) to the sophisticated (like KDE for a netbook). Over time, as more partners join, the set of supported “heads” will grow – ideally in future you’ll be able to bring up a Gnome head, or a KDE head, or a Chrome OS head, or an Android head, or a MeeGo head, trivially. We already have goot precedent for this in Ubuntu with support for KDE, Gnome, LXE and server heads, so everyone’s confident this will work well.

The diversity in the Linux ecosystem is fantastic. In part, Linaro grows that diversity: there’s a new name that folks need to be aware of and think about. But importantly, Linaro also serves to simplify and unify pieces of the ecosystem that have historically been hard to bring together. If you know Ubuntu, then you’ll find Linaro instantly familiar: we’ll share repositories to a very large extent, so things that “just work” in Ubuntu will “just work” with Linaro too.