One Linux for all ARM systems

One Linux for all ARM systems

Summary: At long last, we’re on our way to a single Linux kernel for all ARM smartphones, tablets, and other devices.

SHARE:
ARM Powered
Linux unification is coming to the ARM processor family.

ARM processors and Linux have been married for years. You name an ARM-based device—smartphones, Raspberry Pi, tablets—and you’ll find Linux running beside it. It’s not been a happy marriage though. For every ARM system on a chip (SoC) there had to be a different Linux spin. With the forthcoming Linux 3.7 kernel we’re on our way to seeing all ARM processors working with a single Linux kernel.

The problem has always been that while the ARM processor family itself has stayed unified, every vendor’s SoC supports its peripherals in different ways. On x86 PCs we've always had the BIOS, and more recently the Unified Extensible Firmware Interface (UEFI) to provide a common application programming interface (API) for the Linux kernel to hook into. With ARM SoCs, you couldn't even count on something as generic as General Purpose Input/Output (GPIO) using the same APIs and working the same.

Over the years, as new ARM SoCs and end-user devices have flooded the market, this has really ticked off low-level ARM developers. They ended up having to reinvent the wheel with almost every new chip and device to come down the highway. The higher-level Linux developers were even less happy.

On March 18, 2011, Linus Torvalds had had enough. He wrote, "Gaah. Guys, this whole ARM thing is a f**king pain in the ass."

Torvalds continued, "You need to stop stepping on each others toes. There is no way that your changes to those crazy clock-data files should constantly result in those annoying conflicts,just because different people in different ARM trees do some masturbatory renaming of some random device. Seriously."

It's not that Torvalds didn't want to work with them. It’s that there was no consensus within the ARM community. "Somebody needs to get a grip in the ARM community. I do want to do these merges, just to see how screwed up things are, but guys, this is just ridiculous. The pure amount of crazy churn is annoying in itself, but when I then get these independent pull requests from four
different people, and they touch the same files, that indicates that something is wrong," he wrote.

How bad was it really? David Rusling CTO of the Linaro Linux-on-ARM coalition, wrote later that year, "As an indication of the scale of this problem, each new kernel release sees about 70,000 new lines of ARM code, whereas there’s roughly 5,000 lines of new x86 code added." That’s a lot of code to write and clean up with every new release.

What made it especially annoying was, as Torvalds saw it many of the changes were totally unnecessary. "Stop the crazy renaming already!" Torvalds yelled. "Just leave it off. Don't rename boards and drivers ‘just because,’ at least not when there clearly are clashes. There's no point. I'm not even talking about the file renames (which happened and can also make it "fun" to try to resolve the conflicts when somebody else then makes _other_ changes), but about the stupid "change human-readable names’ in board files just to annoy whoever needs to merge the crap."

Torvalds concluded, "Somebody in the ARM community really needs to step up and tell people to stop dicking around."

The ARM developers got the message.

Torvalds was pleased this month to announce that he was merging multi-platform ARM code into the mainline Linux kernel. Olof Johansson, a Google Linux and ARM engineer, has been working on the project and wrote, "This is a pretty significant branch. It's the introduction of the first multiplatform support on ARM, and with this (and the later branch) merged, it is now possible to build one kernel that contains support for highbank, vexpress, mvebu, socfpga, and picoxcell. More platforms will be covered over in the next few releases.

To make this happen, Johansson wrote, "Two critical last things had to be done for this to be practical and possible:

* Today each platform has its own include directory under mach-<mach>/include/mach/*, and traditionally that is where a lot of driver/platform shared definitions have gone, such as platform data structures. They now need to move out to a common location instead, and this branch moves a large number of those out to include/linux/platform_data.

* Each platform used to list the device trees to compile for its boards in mach-<mach>/Makefile.boot.

Johansson knows this won’t be easy. "Both of the above changes will mean that there are some merge conflicts to come (and some to resolve here). It's a one-time move and once it settles in, we should be good for quite a while."

It’s also not ideal. But, unless the ARM vendors can ever agree to an equivalent to the BIOS ir UEFI, having a single directory structure for each ARM SoC’s devices is a heck of a lot better than having to create a customized Linux kernel for every last, lousy SoC

The amazing thing is just how popular ARM devices has been without any rhyme or reason on the low-level programming level. With this in the works, it will be possible for ARM/Linux vendors to innovate more quickly and get their products out to market faster.

Related Stories:

Topics: ARM, Hardware, Linux, Open Source, Smartphones, Software Development, Tablets

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

31 comments
Log in or register to join the discussion
  • Now if we can just move this naming

    convention into the regular UNIX variants. The difference between a HPUX administrator and a SUN administrator is that you memorize a different set of file locations. Oh, and the SUN guys have a heck of an attitude problem if you aren't using Solaris, just because you aren't using the blessed OS. Far too many of these guys went on to Linux. Their status is how many obscure file locations they have memorized. Leave it to the founder to kick some ex-SUN administrator butt!
    Tony Burzio
  • Yawn -

    In all reality, the ARM version of Linux really doesn't matter to most people. The phone or device they get works, so they don't care about whether a library was renamed for some inane reason or not. The overall article gets a big yawn.

    I guess this really shows how disjointed the Open Source community can get. At least Torvolds can badger them into cooperating.

    On the other hand, it's kind of like Steve Jobs, when Torvolds steps aside, who will have the clout to badger the competing groups into place?

    Has Torvolds risen to the position of benevolent dictator in the Linux world, sort of like Gates was at microsoft, ensuring that everything works? When he steps aside, who will fill his shoes?

    Who can pull it all together? Wait and see-
    Cynical99
    • Not just ARM-based mobile devices

      ARM-based servers too. There will be server farms and data centers running ARM-based servers. And they will consume significantly less energy and require significantly less cooling than those based on the current crop of i86/i86_64-based servers.
      Rabid Howler Monkey
      • Not for a while

        You won't see ARM in quantities of servers until we have proper 64-bit support - which is also in a similar mess as the firmware I/O problem.
        Joe_Raby
        • Yeah

          And, the performance isn't up to scratch either.
          sjaak327
        • RE: Not for a while

          Perhaps, early 2013, then? It's getting close. More here:

          http://www.zdnet.com/arm-server-start-up-calxeda-gets-55m-cash-infusion-7000005473/
          "I understand that Calxeda is getting ready to unveil a new server design. There's a slim chance this could be a 64-bit capable platform, as ARM announced its first 64-bit chip designs in October 2011. This timing means chips based on the designs could be manufactured by the first half of 2013.
          "With the launch of ARM's 64-bit chips next year, it will become easier to tell whether the low-power use is attractive enough to cause a transition away from x86. These investors are betting that is the case.
          Rabid Howler Monkey
          • At least one is already available

            http://www.calxeda.com/technology/products/processors/ecx-1000-techspecs/
            jessepollard
    • Yes thats true, but thats not the focus

      Most people couldnt care less that Android is Linux for example, but theyre not the ones caught up in it.

      The engineers trying to give you users the unified and capable platforms you ask for have been fighting with each other over different designs that should instead be the same, just to do so. No-one else has yet come up with a standard, which is whats needed and what Linus is trying to provide.

      Just because you are an end-user, and as a result used to the proprietary and fractured desktop experience, that doesnt mean we all are. Those who build the world need better tools, and it is important to anyone who just tinkers as well. I tinker, using SOCs like Beagle and Pi and Gumstix, and it would be so much simpler if I didnt have to write code for each, or fight to get the OS onto the SD card, or into the SDRAM onboard because they are all different...

      I found the article to be interesting and informative, where I dont often agree with SJVN.
      SiO2
    • A few of us here actually do embedded ARM

      We've experienced many of the update frustrations.

      New direction a positive for us, lowers barrier of entry for other developers, no negatives for others. A win-win-win.

      Good article, more of them ZDNet.
      Richard Flude
  • This is a great step forward

    The utter lack of any form of standardized device/feature metadata modeling (which is essentially what the BIOS/UEFI provide) is a MAJOR hindrance when building platform level code (i.e. OS code) that needs to run on multiple ARM devices.

    I know that Microsoft had to deal with a lot of the same issues when porting Windows to run on ARM and has come up with a pretty elegant solution. That said, this is the primary reason why you won't be able to just install Windows on any old ARM device - each and every ARM device comes with device-specific and often device-model-conflicting configurations.

    Hopefully, ARM SOC vendors will buckle down and agree on a standard device/feature description models/mechanisms, like UEFI perhaps. If the ARM ecosystem wants ARM devices to compete with Intel as a general-purpose computing platform, they're going to HAVE to.
    bitcrazed
    • Microsoft requires UEFI for ARM

      ....but it still hasn't solved the chip fragmentation issue.

      Also, this is why Microsoft is locking down OEM hardware with ARM. Linux on ARM doesn't properly support UEFI for ARM so you wouldn't be able to install Linux on it anyway, even if you wanted to, no more than if you wanted to buy a cheap dev board and install Windows RT on it (since they don't have UEFI).
      Joe_Raby
  • is the lack of a BIOS equivilent

    why ROMs have to be compiled from source for every single device separately instead of being able to make 1 ROM and have it load on any device like you can do with every x86 OS?
    theoilman
    • Wild west

      Basically every Arm manufacturer make their own custom modifications to their Arm processors.

      To have the source code, makes the transition from x86 to Arm much easier. You don't need the original developers to come with an Arm version of their program, since you can compile the code. In open source you can automatically compile the program code for your version of Linux on a very exotic new type of processor your company developed.
      Oden79
      • automatically compile the program code for your version of Linux

        No, no you can't. You have to build a custom kernel, customize your OS and customize many apps for each and every ARM SOC you target.
        bitcrazed
      • Ahh, child-like wonder...

        ..how I miss those days when I thought there was magic in the world.. and I'm sure your ARM compiler will be magically delivered by the source-code fairy, too!
        daftkey
    • Re: compiled from source for every single device separately

      Because that way you don’t end up with any extraneous junk that’s not relevant to your hardware.

      That’s the great thing about having the source code.
      ldo17
  • This Is Probably Also Why Windows Can’t Get Any Traction On ARM

    Microsoft is accustomed to a pliant herd of OEMs/ODMs who will obediently follow its every direction, while the ARM world is basically organized anarchy. Linux thrives in such an environment, where there is no centralized hierarchy giving orders to everybody else, where the overriding principle is “rough consensus and working code”.

    Anybody who tries to insist on a top-down way of doing things will just be left there standing bewildered as the tides flow around them. Market shifts can happen very quickly in this business, and you have to be agile to keep up.
    ldo17
    • Windows Can’t Get Any Traction On ARM? You make this stuff as you go along?

      It's obvious to all that you are anti-MS, but the more make believe you post, the less seriously people take you.

      Just an FYI.
      William Farrel
      • ...

        William Farrel, an Micro$oft employee has spoken ....
        Watchmen247
  • Screen and Tv:s

    Very interesting when you soon can build very good computers for a few dollars. At some point every screen and TV will have a built in computer for everyday work. When something became cheap and common enough feature, it will be build in as standard. In the future:

    Customers asks in a store for screen without built in computer. Seller says we only got screens with build in computers in stock, but we can order one for you without computer. It will take two weeks and since screens models without built in computer are no longer mass produced, it will cost $50 extra. Are you sure you don't want to buy exactly the same screeen with built-in computer for $50 less than the one without?
    Oden79