One Linux for all ARM systems
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: