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."
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.
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