Slashdot Mirror
The Ugly State of ARM Support On Linux
jfruhlinger writes "Power-efficient ARM processors are moving up the food chain, to the extent that even Windows will soon see an ARM port. Linux, which has long been cross-platform, should have a long head start in this niche, right? Well, blogger Brian Proffitt explains just how messy the state of Linux support for ARM is right now, partially as a result of mutually conflicting kernel hacks from ARM manufacturers who just wanted to get their products out the door and weren't necessarily abiding by the GPL obligations to release code. Things are improving now, not least because Linus is taking a personal hand in things, but sorting the mess out will take time."
ARM manufacturers are idiots
Intel gets open source, most ARM manufacturers don't.
Hence, most BSP rely on proprietary drivers, they don't have up-to-date support for devices in the mainline kernel, etc
Also, there's a lack of a 'standart platform', even though ARM is pretty much homogeneous
Things are beginning to change, still. And ARM is still miles ahead from SH, embedded MIPS, etc
how long until
The ARM vendors (TI, Samsung, etc.) do release their kernel changes. What they do not do is work with Linus and RMK on getting their code merged upstream. The GPL does not require that they do that.
Having worked on bring-up on three custom ARM projects, I can personally attest to how gnarly it can be. But it's not necessarily something that Linus will be able to fix, or the Linux kernel community at large.
The main problem is the custom board support - even though the source code is GPL, they give you full source code and even submit it to back into the eco-system, it's just haphazard code that was pushed out the door too quickly. Linus can't stop people from writing bad kernel code, he can stop them from submitting it back into the mainline, but thats kind of what we have right now. If your code isn't up to snuff it doesn't make it into mainline. That doesn't stop them from shipping a product and giving that code to customers.
In one case, the documentation for the ARM chip I recieved was a password protected PDF that you can't even cut text out of, describing how to use the features by writing your own device driver. In that case, they had minimal Linux support but for all the bells and whistles you had to do it yourself.
The problem is as dense and layered as the chips themselves - what really needs to happen is a standardized method for publishing SoC features in a structured format (XML?) where common features (FIFO registers with a bytes_remaining field? Write only configuration registers, Read only configuration register.. etc) could be defined and the code could in many cases just be automatically generated.
Need to set reg A to all f's, reg B to all zeros, flip bit 12 of reg C and then your PHY is configured - done.
For more complex interlocking mechanisms that would be difficult or impossible to communicate in a cure-all DSL, but even if you could eliminate 80% of the problems that'd be great.
Which brings me to the other problem - a lot of what you do to get ARM systems up and running happens way before you run Linux - in U-Boot/RedBoot or whatever else is out there.. And thats a whole other kettle of fish.
weak ARM support is very much related to the constantly moving target of ARM hardware. there are several series of ARM cpus in use today and as soon as one becomes commonplace, it is phased out in favor of a "cheaper and better" cpu, sometimes in the same series, sometimes not.
this phenomenon is related to wireless providers having an economy of scale that doesn't make sense in an end-user context. for them, having a team of skilled programmers that cost > USD 10 mln / yr is nothing and they leverage the hell out of this fact. expect this sort of stuff to continue despite ARM cpus comprising the majority of cpus on the planet.
I didn't have a speed problem with my NSLU2 (not overclocked), but the memory (32M) seemed insufficient. It doesn't matter how fast your processor is if you spend 90% of your time swapping.
Do you even lift?
These aren't the 'roids you're looking for.
The Windows Mobile and Windows NT kernel are not the same thing.
Anyone remember it?
Remember during the days of kernel 2.0 or 2.2 a decade ago you could buy a Netwinder appliance that came iwth Redhat Linux? Corel even shipped WordPerfect for Unix on it, and I remember reading a commentator who used it on LinuxMagazine.
ARM support has been supported in Linux for a very long time. This story is pure FUD.
I know this is Slashdot and reading the article is sacrilegious, but you could at least read the summary!
Well, blogger Brian Proffitt explains just how messy the state of Linux support for ARM is right now, partially as a result of mutually conflicting kernel hacks from ARM manufacturers who just wanted to get their products out the door and weren't necessarily abiding by the GPL obligations to release code. Things are improving now, not least because Linus is taking a personal hand in things, but sorting the mess out will take time."
Nobody's challenging that ARM is supported by Linux. This article is about how Linux's ARM support is poorly-coded and internally-inconsistent. The problem is that the ARM code is neither scaleable nor maintainable. This is critical as both the Linux kernel and number of ARM systems supported continues to grow, which it almost certainly will.
It is pretty foolish to blow a Linux kernel issue off as "FUD" when the maintainer of said kernel himself is taking action to address it.
>> a threat that could effect dozens of companies' livelihoods
A lot of semiconductor companies were releasing linux-based SoCs way before the mainline kernel started consolidating code from vendors. If Linus stopped pulling ARM code, no business would shut down. I personally don't know any companies that rely on Linus' tree to ship their customers.
>> To make matters worse, even though the GPL v2 license on the Linux kernel requires these changes to be released back upstream to the main Linux kernel, often they were not.
This doesn't make any sense to me. GPL requires the changes to be released to the person who purchases your device/code. The vendors have zero responsibility to the mainline.
>> ...this is entirely the reason why the non-profit Linaro consortium (...) was put together...
One thing I wonder about Linaro is how they are going to be the leader and not play catch up. There are a lot of board-specific drivers they can consolidate, but as they consolidate, the vendors are coming out with even more.
>> [a]s 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."
I find this comparison very unfair. Yes, that 70K number could be more like 20-25K but the devices with ARM processors have very different structures, designs, and end goals. One code can't fit them all. On the flip side, most x86 implementations are on either desktop or server side.
I'm surprised Likely didn't talk about the device-tree support for the ARM tree. I've implemented a few (ppc-based) boards with device trees. The initial learning curve was a bit painful, but once you understand it, it enables a lot of common code and cuts down development time too. synthesizerpatel above mentioned "a standardized method for publishing SoC features in a structured format" above and the device trees are exactly it (except they're not XML! so, even better!)
My preference as a lowly bring-up guy would be if the desktop/server kernel split up from the embedded kernel completely. Embedded kernel devs then can emphasize what's important to them (cut down development time, wide variety of device support, aggressive power mgmt) while the desktop/server devs can focus on their stuff.
That is because the slug is old hardware, wasn't exactly high end when it was released and was bought in large numbers by linux hobbyists. So it's well-known but slow. The shortage of ram doesn't exactly help either (it's possible to upgrade it but it's not for the feint hearted). Modern arm hardware is faster though there are speed issues caused by the floating point mess.
AIUI the big issue on ARM is lack of a standard platform.
On a PC you can assume you have a BIOS that can load stuff from HDD and execute it in an environment with basic disk access services. You can assume the addresses of most of the basic hardware (real time clock, interrupt controllers etc) You can generally assume there is a PCI bus for auto-configuration of other devices and that PCI bus has it's configuring space mapped to the processor in a standard way. There is a standard way of reading out how much ram there is and how it's mapped and so on. These things mean you can build one kernel and use it with one bootloader on pretty much any PC.
On arm afaict there is no standard platform. Therefore each arm processor and sometimes each arm board needs specific support to tell the kernel things like how to find out where stuff is mapped in the processors address space, how to find out how much ram there is and all the other quirks of the new system. Often these things are hacked up as quickly as possible by vendors who want to get a working system out which appears to be what is pissing linus off*.
There is also the floating point mess. ARM has been used with many floating point units over the years. Right now there is one that is most common and debian at least seem to have decided that the way to go is to build two ports, armel for systems without FPUs (or systems with unsupported FPUs) and armhf for systems with vfp but if vfp falls out of favour then they will be left with either adding yet another port or trying to hack something up. Also afaict there is no easy way to migrate between different debian arm ports without reinstalling.
* and afaict pissing linus off is bad because if he doesn't merge code then it tends to bitrot unless it has very active maintainers.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The Kernel isn't the only thing suffering from shoddy support. The ARM backend and code generator for GCC is suboptimal. The GCC __sync_* builtin functions for atomic memory access are unoptimized and call into kernel functions, which isn't always necessary, hopefully this will be fixed with the new C1x/C++0x atomics and memory model. And then the ARM NEON neon intrinsics/builtins implementation is in an absolutely horrendous state, I'm surprised NEON register allocator is even functional.
I'd fix it myself, but then I'd have to spend 2 months learning how to make changes to GCC, and wait another 6 months for my patches to be accepted.
it is OSS in general with respect to ARM support.
My God.... the state of Angstrom, BitBake, OpenEmbedded... while the maintainers are doing great work, they are not nearly as stable and mature as established architectures.
Seriously, check out OpenEmbedded and try to roll that latest Gumstix omap-console-image. Count the number of things that are broken. It is a travesty!
This kind of shite would NEVER be accepted in a mature x86 based project.
I am very small, utmostly microscopic.
i know this article is slightly trollish, but it did make me wonder.
what's going to happen when Linus finally retires? will there be strong enough leadership in the ensuing vacuum? in spite of open-source philosophy, will linux remain Linus' brainchild?
I think you're missing two points. One, except for the claim that some smaller ARM vendors might not be so diligently releasing their kernel source changes, the articles points out bigger vendors (presumably including TI, Samsung, etc) are complying properly with the GPL. Two, the article/blog was going out of its way to explain that some ARM vendors not working to get their code merged upstream is a bad thing and that it might result in some vendors code not at all being merged in the mainline kernel.
As much as nothing about the GPL requires that vendors try to merge code with the mainline of a open source project, it's in the same vein true that nothing about the existence of extant roadways/railways/waterways requires anyone to use them. It's just general stupid for most companies to outright avoid them, especially when it comes to building the smaller pieces that bridge to their front door or effectively damaging those transport pathways heavily in use. If an ARM vendor wants to reinvent the wheel while many other ARM vendors are cooperating upstream, they'll likely end up producing repeated code in the short term, increase code management issues in the long term, and have lengthy rewrites/patches/merges in their own forks if they every choose to try to realign with the mainline kernel in the future.
In short, the issue isn't very much about what GPL requires legally. It's that there's a synergy in cooperation that licenses like the GPL were meant to embody and are frequently used for, where many people can benefit from working together and share the fruits of that effort. Any vendor can always choose to "go it alone", but except in some circumstances it really doesn't make sense for the long term.
Eurohacker European paranoia, gun rights, and h
Quite right. Good explanation of the issues. Fans of Linux and ARM often have difficulty grasping why support for the CPU architecture is not enough. Linux must support the system architecture as well, and if every SoC has a different architecture (and they do), then that's going to be really messy.
You're an immobile computer, remember?
It doesn't matter how fast your processor is if you spend 90% of your time swapping.
THAT needs to be publicized on all computer vendor's sites, prominently, so that even the most feeble minded consumer comes to understand it. I was involved in a discussion recently, among GAMERS or all people. A guy on a budget needed to be convinced that he would do better with an older, slower processor and > 4 GB of memory, than he would be with the fastest CPU he could afford, but only 2 GB of memory. Assuming Windows 7 was to be installed, along with a long list of "networking" apps, (teamview among others), those 2 gig of memory would have been woefully inadequate.
Any vendor today who sells a 64 bit computer with less than 4 GB installed memory should be sued for misrepresentation.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I had a couple of NSLU2's. One tran a simple web server, IMAP and POP3 mail servers (with all sorts of spam filtering) and ssh server. The other ran mediatomb and torrenflux.
The mail server had a 4GB USB stick as it's main drive for several years, the other had a hard drive in a USB caddy which made a hell of a speed difference.
They weren't exactly quick but they were cheap and low powered. If you cut out everything you didn't need (and I mean everything) from the standard debian distro, you could get an acceptable system running. Then I bought a sheevaplug and the difference was incredible. Modern processor, modern speeds, comparatively lots of RAM...
I've also been making kernel alterations for the WD Sharespace, and have dug into the arch/arm source tree. It's not *that* messy, it just has loads of different pieces of initialisation code depending on processor variants, board types, attached devices etc etc
I imagine its very similar to what I find rewriting libraries for microcontrollers from various vendors and even different micros from the same vendor. While they all have similar hardware I.E. a CAN interface, there is no standard way of configuring the hardware for bit timing, or message ID's or acceptance masks and filters, the number of available mailboxes and their functionality differs, message tx rx signaling, interrupt types, error reporting, register descriptions, its all different! ADC's are the same way, timing, triggering, re-triggering, addressing, configuring, accessing, input scaling, reference source, result scaling, register access, all different for essentially (IE a 10 bit successive approximation ADC) the same hardware.
Every single one of the various little tidbits of IP that gets added is different from each and every manufacturer!
No two vendors do anything the same. And one would probably be sued by the other if they did. We had to get special approval from Motorola to have Infineon replicate similar functionality in one of their DSP's to allow us to use the same code output from Simulink across multiple ECU families.
You have to be different to be better, and all these vendors implement features attempting to be the best so you have a reason to purchase their device over the other 10 that are essentially just like it.
Makes it very difficult on the person developing the API to have consistency across multiple platforms without dumbing it down to lose some features striving for a common set, or having slightly different API's or slightly different usage per micro, or designing them around an application, and hiding much of the other functionality.
Cheers!