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."
weak ARM support is not surprising (Score:3, Interesting)
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.
Re:Problem is simple (Score:5, Interesting)
Not true. Almost every device released today has full driver support in the kernel sources that are dropped. Userspace components notwithstanding, the kernels released are fully capable of supporting other OSes when recompiled (assuming the device will boot them.)
What does happen, however, and I stated this elsewhere, is the drivers are released ONLY into those tarballs with no revision history, full of android-specific code and are never merged upstream into the kernel. This makes porting newer kernels to the device even harder, which you can see in the 2.6.36 and 2.6.37 changeup in how some sound drivers are structured. As a result, you've got tons of drivers for hardware sitting, and rotting, in obscure folders on corporate websites.
And all this mess is before the schism created in the userspace by Android.
Re:Problem is simple (Score:4, Interesting)
Also, there's a lack of a 'standart platform', even though ARM is pretty much homogeneous.
Kind of. Actually things are not that bad. There are a lot of SoCs out there which bundle an arm core with a few other cores (ethernet, usb, etc). There are actually staggeringly few vendors for the peripheral cores. The SoC vendors don't generally mention who the core vendor is, but they provide a datasheet and stick the core at some random place in the address space.
As a result, there are a lot of reimplementations of the same drivers. This has been recognised and peopls are now trying to spot duplicate drivers and replace them with a asingle unified one.
Re:NSLU2 (Score:5, Interesting)
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.
Re:AMEN (Score:5, Interesting)
You think it's gnarly now? You should have seen it a couple of years ago! Things have improved by light-years since then.
It's true that ARM isn't as cleanly supported as, say, x86. But the simple explanation is that there is significantly more diversity in the ARM world than in the x86 world, so comparisons between the two are a bit like comparing apples to orangutans.
There are limits to what can be done to address the problem. I prefer having a diversity of ARM chips to having a BIOS--- and that would be the only way to tame this beast long-term. I think most platform developers (those who do both hardware and software) would agree with me: it's easier to port Linux to a good chip for your end application, than it is to use a less-than-ideal chip in the platform just because it has a mature Linux port. So while we should continue refactoring Linux on ARM, we should also accept that things will never be as clean as they are on x86. It isn't in anyone's best interest to even strive for that goal.
In parallel with all of this, we must be careful not to kill the goose that lays the golden eggs. ARM is the singular reason why Linux owns the embedded space for 32-bit CPUs that run OSes. Nobody else is even close. So despite all of Linux's warts for ARM, it still works really, really, REALLY well. Vendors of ARM SoC's should recognize this, and pony up some funding to clean up the mess as an investment in their futures.
Re:AMEN (Score:4, Interesting)
I don't know if such a standard SoC description format could ever exist in a useful form. Anything even moderately complex would require driver code, not just descriptive data. Descriptions produced by vendors would inevitably be buggy, like ACPI data. This solution would probably just make the problem worse.
It would be much better to simply standardise the SoC, so that every ARM system has the same basic elements. Just like a PC, where the interrupt controller and memory are always in the same place, and the timer always has the same register map.
I assume that SoC vendors do not do this because (1) they don't need to, (2) they want to have "value-added" features like their own custom power management subsystem, and (3) the diversity makes it harder to use a different SoC as a drop-in replacement.
But they should standardise. There's no advantage to the user, the OEM, or the OS developers in having so many different SoCs.
Re:Problem is simple (Score:4, Interesting)
Here's my experience. I did a project for a company that were producing a SoC themselves. We were using the designware SPI peripheral. We wrote the driver ourselves (don't remember right now why - the dw_spi module was not for the right chip or something along these lines. I didn't do the original development).
Turns out this chip doesn't have proper peripherals support. No NAND controller and no integrated MAC, so we use SPI for both persistent storage and for networking. Except the chip isn't fast enough to service the "SPI queue is almost empty" interrupt, despite the designware having a huge queue (256 bytes), and no matter how high we place the watermark, so we do some serious trickery in order to get things working (in essence - directing SPI chips select to a GPIO and manually controlling activation and deactivation). Poor SPI throughput. Worse, the driver is now unsubmittable, as it contains hacks which really only make sense to this particular chip.
So I come along, and suggest to hook the SPI driver to the existing on board DMA controller. Get the whole buffers through without the CPU needing to do anything. A bit of hard work, and the DMA is working (not improving performance, but that's another story). Except neither the DMA infrastructure nor the actual hardware are generic enough to do such a thing so that I don't care which DMA controller is hooked into the SPI controller. So, more hacks. In theory, I could rework the infrastructure so that it is more generic, but that's a project that will cost (man hours) about as much as the original SPI driver rewrite.
The project wound up being canceled, so things never progressed any further, but you can understand that none of that code was ever released. This is not due to the client's desire not to release. Search for Baruch Siach's contributions in the enc286 code for example of vanilla integrated code that were done on that client's dime and with their consent. It's just that there is a limit to how much time a company can authorize merely so that the code is generic enough to go into main.
Shachar