The Ugly State of ARM Support On Linux 94
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."
The GPL remarks GPL in the article are nonsense. (Score:4, Informative)
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.
AMEN (Score:5, Informative)
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.
Re:Problem is simple (Score:4, Informative)
I wasn't talking about Android, but the point stands.
If wireless controllers on Android devices don't depend on proprietary drivers, great! That's a start
But try Hw accelerated video playback, 3D drivers, etc
And some products absolutely depend on those. Think set-top-boxes, multimedia players, etc.
Re:Problem is simple (Score:5, Informative)
Working on MeeGo makes me all too keenly aware of that mess. None of it really applies to the kernel though, since all interesting bits are in userspace. And the graphics core IP vendors (Qualcomm most notably) have already been refused entry into the kernel because of this.
The Ugly State of ARM Support on GCC (Score:4, Informative)
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.
Re:Get Radical: Raise Social Security (Score:2, Informative)
Re:NSLU2 (Score:4, Informative)
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!