The Linaro consortium debuts

[Posted June 3, 2010 by corbet]

ARM, Freescale, IBM, Samsung, ST-Ericsson and Texas Instruments have announced the creation of a new nonprofit organization called Linaro which is aimed at helping the creation of mobile Linux-based systems. "Linaro will work with the growing number of Linux distributions to create regular releases of optimized tools and foundation software that can be used widely by the industry, increasing compatibility across semiconductors from multiple suppliers. As a result, Linaro's resources and open source solutions will allow device manufacturers to speed up development time, improve performance and reduce engineering time spent on non-differentiating, low-level software. Linux distributions, open source and proprietary software projects will benefit from Linaro's investment, with more stable code becoming widely available as a common base for innovation."

The Linaro consortium debuts

Posted Jun 3, 2010 13:53 UTC (Thu) by pabs (subscriber, #43278) [Link] (12 responses)

The press release seems like an exercise in writing as many words as possible that provide as little information as possible. What does this actually mean? Thankfully we have Mark to interpret it for us:

http://www.markshuttleworth.com/archives/427

The Linaro consortium debuts

Posted Jun 3, 2010 13:55 UTC (Thu) by ctg (guest, #3459) [Link] (8 responses)

Is it Meego for corporates who don't like Intel/Nokia?

The Linaro consortium debuts

Posted Jun 3, 2010 14:30 UTC (Thu) by ewan (guest, #5533) [Link]

It looks a bit more hardware oriented at first reading; an attempt to get a consistent platform for ARM in the way that the PC is for x86.

The Linaro consortium debuts

Posted Jun 3, 2010 14:34 UTC (Thu) by kragil (guest, #34373) [Link] (6 responses)

IMO more like: Corps who don't like Intel and RPM.

The Linaro consortium debuts

Posted Jun 3, 2010 15:33 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

Doubtful if you can provide any evidence to support that. Businesses do whatever makes them money. Many of these organizations are happy to work with Intel or RPM based distributions if it makes more money for them.

The Linaro consortium debuts

Posted Jun 3, 2010 18:57 UTC (Thu) by drag (guest, #31333) [Link] (4 responses)

Well the only evidence I see is that Intel is a major competitor that would like to see all the different ARM variants be utterly destroyed and replaced with Intel-specific processors and chipsets.

The other evidence I see is that Debian is the only major Linux distribution that has top-notch support for non-x86 stuff. Between Debian vs everything else I'd definitely choose Debian.

How many other distributions do a good job of providing cross-compiling toolkits and the easy ability to run non-x86 code on a x86 machine via qemu?

The Linaro consortium debuts

Posted Jun 3, 2010 22:24 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]

Gentoo?

http://www.gentoo.org/proj/en/base/embedded/handbook/

The Linaro consortium debuts

Posted Jun 4, 2010 3:29 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Intel and ARM compete with each other more aggressively than before and that's a good thing! Meego is RPM based and took advantage of the Fedora ARM effort. It is myopic to think that companies hate each other or any particular technology. Every major IT company that I am aware of is willing to compete or partner with other companies and work with operating systems or package management systems or whatever opportunistically.

The Linaro consortium debuts

Posted Jun 4, 2010 8:24 UTC (Fri) by kragil (guest, #34373) [Link] (1 responses)

Yeah, like Apple and Adobe with regards to Flash. Totally rational behavior, no feeling whatsoever involved.
IMO all the Linaro folks see Meego as Intel-controlled and RPM focused, which is probably the right way to see it although it is a Linuxfoundation project.
So Canonical and the ARM vendors made their own. I don't think they have many problems with the Nokia/ARM(and now obsolete Maemo) side of things.
But don't get me wrong, I think Linaro is a worthwhile effort.

The Linaro consortium debuts

Posted Jun 4, 2010 10:57 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

I didn't claim that there is no feelings possible but you will notice that Adobe and Apple continue to work together on many things still. You can bet that they will be willing to set aside difference if Flash was actually crucial to Apple's success. In this case, there is no evidence to claim that this consortium is somehow anti Intel or especially anti RPM. That is just nonsense.

The Linaro consortium debuts

Posted Jun 3, 2010 14:50 UTC (Thu) by DavidRusling (guest, #67100) [Link]

Yes, Mark's outline is a good one. Think of it as a collaboration vehicle for the ARM partnership. For more information, have a look at http//www.linaro.org/developer/. We're concentrating our initial efforts at tools and kernel.

Mark's interpretation

Posted Jun 3, 2010 16:10 UTC (Thu) by clugstj (subscriber, #4020) [Link] (1 responses)

Unfortunately, Mark's "interpretation" sounds much like the blather that we get regularly from the CEO of the company I work for.

Since they just announced it today, no one knows yet what it will be. We'll have to wait and see.

Mark's interpretation

Posted Jun 3, 2010 23:32 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Canonical is heavily involved in Linaro, so Mark certainly knows what it's all about.

The Linaro consortium debuts

Posted Jun 3, 2010 15:25 UTC (Thu) by amit.kucheria (subscriber, #59246) [Link] (14 responses)

The idea is to be distro-agnostic and fill the gaps where ARM (on Linux) is currently lacking - consolidated kernel, bootloader, tools, toolchain.

All the work will be directly done in upstreams.

The Linaro consortium debuts

Posted Jun 3, 2010 15:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (9 responses)

If upstream disagree with a Linaro decision, which direction will things go in?

The Linaro consortium debuts

Posted Jun 3, 2010 16:04 UTC (Thu) by DavidRusling (guest, #67100) [Link]

We aim to work with the upstream, but what they say goes - no forking

The Linaro consortium debuts

Posted Jun 3, 2010 16:09 UTC (Thu) by amit.kucheria (subscriber, #59246) [Link]

If it means refactoring, so be it.

The Linaro consortium debuts

Posted Jun 3, 2010 18:47 UTC (Thu) by Russ.Dill@gmail.com (guest, #52805) [Link] (6 responses)

The biggest effort mentioned was device trees for ARM. That is something that has been on the TODO list for ARM for quite some time, and to get corporate backing for it is huge.

The current state of board support for the ARM kernel largely includes two things. One, drivers for the board (which are often shared between boards and even architectures) and two, declaring what devices exist on that board, how they are connected, etc.

Device trees allow the second to be described either in firmware or tacked on to the kernel rather than running as code (for an example, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...)

Thus, you'd be able to have a kernel boot a board that didn't even exist at the time the kernel was built, so long as it contains all the necessary drivers.

Just one example of a goal Linaro is working towards that upstream supports.

The Linaro consortium debuts

Posted Jun 4, 2010 2:21 UTC (Fri) by tbird20d (subscriber, #1901) [Link]

Device tree has had corporate backing for quite a while. The CE Linux Forum has been supporting it since last Fall. My sense is that Linaro is kind of "CELF for ARM". I hope they are successful. The more improvements, the better.

The Linaro consortium debuts

Posted Jun 4, 2010 6:27 UTC (Fri) by swetland (guest, #63414) [Link] (4 responses)

Sigh. Sticking everything in static tables in the "bios" does not solve the problem. It just means we have to worry about updating two things when stuff's broken. And unless you're going full-acpi-style with some kind of bytecode or whatnot, there's no way to represent all the screwy stuff that happens with real production hardware... and even if you do, now you're maintaining code stuck in the bios/bootrom/etc.

I totally agree that there's a lot of room for improvement, but I'm highly skeptical of device trees as a real solution for real shipping hardware.

The Linaro consortium debuts

Posted Jun 4, 2010 16:17 UTC (Fri) by DavidRusling (guest, #67100) [Link] (2 responses)

You can build the device trees into the kernel rather than rely on a Bios.

The Linaro consortium debuts

Posted Jun 4, 2010 23:10 UTC (Fri) by ai4qr (guest, #64631) [Link] (1 responses)

The preferred implementation of device trees puts the data on the file system or in an accessible partition. This means that in many cases, all you'll need to enable a new device is to change a flat file, without having to reflash anything or rebuild a kernel.

The Linaro consortium debuts

Posted Jun 4, 2010 23:46 UTC (Fri) by swetland (guest, #63414) [Link]

Until you run into common scenarios like "GPIO43 must be used to enable the level shifter on the I2C bus before peripherals X, Y, and Z are enumerated" or "when inactive, you must adjust the GPIOMUX on UART3 to GPIO mode and use a gpio wakeup interrupt because you cannot wakeup from suspend on UART handshake lines without drawing too much power", etc.

I guess if your hardware is extremely rigidly specified, or you're not dealing with typical mobile/consumer device design maybe a device tree will get you going, but I'm skeptical that you'd be able to *ship* something without any modifications to the kernel (I've never seen a case of a not-completely-trivial hardware spin not requiring some annoying software change). Since I've always found that there's need for a per-product kernel build, splitting the board configuration out into some separate chunk of data has never been appealing.

The Linaro consortium debuts

Posted Jun 5, 2010 7:16 UTC (Sat) by glikely (subscriber, #39601) [Link]

Actually, linking the device tree into firmware is strongly discouraged for the reason you mention. Forcing a risky firmware upgrade because the data is bad is not good engineering.

The device tree is not intended to be the end-all-be-all description of how hardware works. It uniquely identifies the board (including variants of the same design). It describes the layout of devices and how they are interconnected. It provides enough information to the kernel so that very few things need to be hard coded. Overall, considerably better than what we currently have.

For the stuff that truly is machine-specific, it provides enough information for the OS to recognize it and choose the appropriate machine support code. Completely eliminating all machine-specific code isn't the design goal. Instead, the goal is to keep machine specific code restricted to the things that are truly machine specific.

(and, for the record, any kind of acpi-style bytecode is not a direction I will be taking the device tree support)

As for being skeptical; no worries. It's used on real shipping hardware now, and I accept it as a challenge to prove to you that it works for real shipping ARM platforms too. :-)

The Linaro consortium debuts

Posted Jun 3, 2010 18:09 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (3 responses)

So you'll be opening up git repositories as part of that upstream focus?

-jef

The Linaro consortium debuts

Posted Jun 3, 2010 18:41 UTC (Thu) by amit.kucheria (subscriber, #59246) [Link] (2 responses)

Yes, git.linaro.org exists now. But there is nothing there yet.

Where possible, work will directly be fed to upstreams. But if there is a need to maintain our trees for that is where it'll be.

The Linaro consortium debuts

Posted Jun 4, 2010 0:27 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (1 responses)

Ah, they have git repos although Canonical is involved and they want to use Launchpad? Waiting for the day Canonical gives up on bzr...

The Linaro consortium debuts

Posted Jun 4, 2010 1:30 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

Canonical's own kernel team has a git repo already at kernel.ubuntu.com as part of their workflow. If Linaro is going to follow an upstream focused development workflow it would only stand to reason that the utility and efficiency of using a git repo would increase accordingly to interface with upstream.

For any of the deep upstream hardware enablement goals that Linaro is shooting for I don't see how they get around having active git repositories to act as staging areas for bits meant to go upstream. I'm not aware of any important existing plumbing layer project that uses launchpad or bzr for its upstream development workflow that requires hardware enablement development work.

And really this isn't an either or situation. Linaro is really two things...an upstream development push as well as a reference distribution deliverable. Its perfectly fine to do your upstream facing development one way...and your binary release management another. In fact it might actually be better.

The reality is, linaro as a release deliverable distribution is essentially Ubuntu-arm. In fact the launchpad page for linaro says as much.
quoting the project page on launchpad https://launchpad.net/linaro
"Also known as:
ubuntu-arm"

And in fact the ubuntu-arm launchpad project redirects to linaro now. The ubuntu-arm/ubuntu-armel/canonical-kernel team members seem to just sort of shuffling hats a bit. That's the really cool thing about Launchpad... how micromanaged team concept is..and how many of the same people show up on a lot of those teams...over and over again. When you look at the team memberships you get a real sense of how over worked the Canonical engineers actually are.

And honestly all that chair shuffling inside Canonical is fine, as long as the development really has an upstream project focus and patches aren't just pushed into bzr as part of a release deliverable package set to meet a release deliverable bullet point.

Moblin if you remember sort of started out this way too.. back when Moblin and Ubuntu-MID were closely tied together in the Moblin V1 days.

-jef