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."
From my experience running Debian with Linux 2.4 on an NSLU2 overclocked to 266MHz (XScale processor), the problem with Linux on ARM is not really stability, but more about speed.
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.
I don't know why people are still acting surprised by Microsoft's support for ARM processor. I had an old Garmin handheld that used an Intel PXA272 Xscale processor that ran WinMo 2003. Maybe full blown Windows isn't ARM friendly but Microsoft has supported ARM in the past.
I guess some people refuse to look into this and see that Microsoft on ARM is nothing new.
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.
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.
http://saveie6.com/
>> 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.
Social security is paid for specifically out of the social security trust fund, which currently has a surplus. Social security has nothing to do with the deficit.
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.
If you want to consider that fund as reall, then you also have to add a couple trillion dollars to the current national debt figures. The fund is just an accounting fiction, money owed by one department of the U.S. government to another.
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
My suggestion from well before kernel modules era. One thing that is needed for the Linux, is a seperation of the drivers from the base of Linux. To do this, create a standard interface for the kernel and drivers to communicate. Probably through the use of Stub drivers in the kernel. This would allow some level of standardization of the kernels, would allow for 3rd party drivers (I know I will get killed for this one), and more importantly is that urgent fixes in drivers could be pushed before the kernel, and may ultimately reduce the size of the distributions, as they would only have to push what drivers have changed.
There is a non-profit consortium called Linaro that is comprised of the ARM players such as Freescale, IBM, Samsung, ST-Ericsson, Texas Instruments, and ARM that get do get Open Source.
There are basically three x86 processor manufacturers. The two smaller players work hard to stay compatible because their livelihood depends on it. Most of the interface functionality is off-chip.
There are many well-known ARM processor licensees. They all strive to differentiate their product offerings. In the majority of cases all of the major peripherals (which are one of the primary opportunities for differentiation) are on-chip.
As such, where minimizing differences by processor was clean and relatively straightforward for x86, expecting it to continue to work well for ARM is nonsensical. I really think Linus is missing the forest on this one.
As such, where minimizing differences by processor was clean and relatively straightforward for x86, expecting it to continue to work well for ARM is nonsensical. I really think Linus is missing the forest on this one.
Not true. Pretty much all of us maintainers agree that the duplication of code and infrastructure in arch/arm is ridiculous. It has to be fixed, and we're actively working on it. Linus was perfectly correct in his statements.
The government is going broke because it is spending more than it takes in, period.
And I listed some reasons why.
Giving the incapable more comfortable lives won't fix that at all
Giving people more comfortable lives is pretty much the goal of society. How you define "people" in this sentence is up for debate: some have excluded blacks, or Jews, or homosexuals, or cripples, etc. You appear to exclude at least cripples. Try harder.
Oh, and of course it'll improve it - though more is needed to "fix it". You give people help when they're incapable and they maintain a certain standard of health which makes them less burdensome to everyone from family up to a national level. Many people can be productive despite chronic illnesses after a sustained period of rehabilitation. Their carers can often be productive outside their caring role providing they're given appropriate support. Many social welfare systems understand the need for the state to have a relationship with a family which supports dependents: it's the choice between an entirely destitute family and a responsible family which takes the burden off the state and which can, as a whole, continue contributing to society at large.
You are, of course, free to donate all of your money to that cause. You're just not free to donate mine.
You have money because the people around you let you have it. This is how all property works in reality: certain property rights are protected because people as a whole regard them as beneficial on balance. If you stop doing what society demands in exchange then society will turn against you and stop offering you protection, and you'll lose what you consider to be "your money". (If you want to see this illustrated, stop paying tax.)
I worked with Marvell extensively in Linux and while it was good all driver support was in their own patch which seemed to not integrate well with the kernel. Parts of it conflicted so I had to ensure certain standard features were turned off. Even userland tools were changed. I had to use a custom version of U-Boot tools. It was a mess. What they don't understand is that they end up spending more time maintaining their patches then just getting them right and submitting them upstream.
One area that is really going to hinder ARM adoption is the boot loader. Most devices use an essentially open source boot loader like u-boot but you can never compile it yourself without bricking your device. There's nothing like the BIOS on PCs that makes it essentially trivial to boot off a CD or USB stick. Most devices have some way to be rescued presumably because the developers need ways to test updated firmware themself but there's no standardisation. I've got a NAS which lets me ssh in during a brief window at boot to get a redboot prompt and a netbook that can boot off a memory card provided it has suitable contrived contents. The trouble is if you can't be sure of being able to update the operating system then the device has a limited life time. Manufacturers are just worrying about delivering a product. Most buyers are happy with it this way but it'd be better if you could easily take your pick of Android, Meego, Windows CE (or 8), Debian etc and install it yourself by simply downloading one file to a USB stick or memory card.
They've changed from herbivores into carnivores?
It was always a retarded expression, but I hoped it had become extinct. I am disappointed to a literally exponential degree.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Windows 8 is supposed to be moving to support ARM and now there's an article suggesting that Linux support for ARM is a buggy collection of hacks and tricks. I'd bet money we'll see more of the same from wide ranging sources. When the Muellertroll writes about it we'll know for certain where it's coming from.
Makes you wonder if you should be paranoid or not ?
I suggest reading of
http://lwn.net/Articles/232379/
http://lwn.net/Articles/445417/
http://lwn.net/Articles/443510/
RISC is old news. Linux was ported many RISC platforms. Anything names advanced makes me wounder if it is advanced. When ARM is ready for real computing it will be ported to real computers.
It's is only news for Windows not Linux. Since ARM will break all backwards compatibility. I wounder if there will be a VM compatibility option? Probably not since Steve Ballmer wants you to buy all new software. We can only hope this will be the final nail in the coffin for Windows.
Great clarification there.
As far as really nasty offenders:
Huawei is one of those "smaller" (at least in terms of the US market for mobile devices) vendors that isn't cooperative. They don't release kernel sources until legally threatened to do so.
HTC seems to think it's OK to wait 30-90 days to release kernel sources.
retrorocket.o not found, launch anyway?
right now you'd have to have balls the size of a small planet to try a true fork
How big are Google's "little witnesses"? It already maintains a fork of Linux for its Android OS.
I have a couple of GuruPlugs and OpenRD's. One of the openRD's is my NAS/dhcp/etc server. I just spent a week trying to get a newer u-boot to boot from USB with some consistency. Probably 3/4 of my time was spent fighting to get a u-boot and linux build that worked properly together. The remaining 1/4 was actually fixing the problem.
The list of sins on these devices is _VERY_ long. A partial list includes:
Some employees try to upsteam some patches. They are free to do so since the vendors' trees are public anyway (you can go look at what the big boys are doing to get 3.0 running right now) Most would probably LOVE to see their stuff merged upstream (either to Linux mainline or at least to Google's) so that they don't have port patches to new kernel versions.
A few reasons you don't see more upstreaming:
- Some of the code is chip specific (errata, custom IP)
- The market demands fast iteration, so having an engineer work to get his patches merged upstream is quite a thorn in the side when considering the time frame that can take.
- A lot of the code that is submitted upstream is flat out denied already (for expected reasons: not elegant enough, too "my way or the highway" on part of vendor)
It does look like Linus really wants to be able to build a generic kernel to be able to boot up on any ARM. That seems to be what Linus and company are getting at. Because currently you have to build the kernel with a specific configuration to be able to boot a specific SoC.
Really a lot of the problem lies in the make process for the kernel... there is just no good dependency handling right now...