Tuesday, November 1, 2011

Whats good for the Goose should be good for the Gander

I think many in the world of FOSS take for granted that a good deal of our x86 compatible hardware works with their operating system of choice. In fact all the fuss about a possible lock out with the coming of Windows 8 attests to this fact. x86 hardware has always been fairly free and it should remain as such right?

Yes it should.

Something that really bothers me though is the fact that ARM hardware is treated in a very different way. What do I mean by this? Well as someone who has worked with over a dozen different pieces of ARM hardware from many different manufactures I can tell you installing an alternative operating system on such a piece of hardware is almost never a pleasant experience.

Before I go on I would like to clarify that by "install" I mean physically run the operating system on the hardware. Not just running it inside a chroot like so many Android users seem content to do on their hardware. In my opinion being told to be content with a chroot setup is just like being told I should be happy simply running Linux inside of Windows via a virtual machine.

Even devices that advertise themselves as open source loving (such as my beloved N900) are a nightmare and a half to install something such as Debian on. Don't be fooled by devices that ship things like Ubuntu Linux by default either. I recently purchased a Trimslice with the hopes of installing Debian on it and it has been an up-hill battle to make it work (one I still haven't won). Once you manage to get the operating system installed even that is only half the process - next you have to hope you can somehow get all your hardware functioning.

Why does all this headache happen? Well, partially it is because of lack of standards in the ARM world. A vast variety of hardware that all have different external components make this task difficult. This difficultly is multiplied two fold when you take into account that most of this hardware has no open specifications. 

In the end my question to the open source community is why is this acceptable for ARM hardware? Why do you continue to rejoice about every new Android device that gets released riddled with closed source modules that are next to impossible to make work under actual Linux.

Just as many of you would be upset if you where told that desktop (or laptop) you bought had to keep it's default operating system I am more than a little annoyed that a good deal of the ARM hardware out there comes with this stipulation attached.

~Jeff Hoogland


  1. Great piece. The Open Source and Free Software folk are different groups. Open source people just care about having enough control and access to do what they want. That's why projects like Cyanogen Mod can satisfy them so easily.

    It's not like they don't care about the Free Software movement, but they only care about the parts of it that benefit them. Organizations and people the agree with the Free Software Foundation have been complaining about locked down hardware everywhere, including on Android and ARM devices.


    I'll admit to being satisfied with small steps like unlocking bootloaders, but I have always wanted complete freedom. I'd love to wipe my phone clean and install ARM branch of Arch with a very custom Enlightenment setup. That simply isn't possible at the moment.

    I also agree with you about open standards. Opening up specifications and settling on standards doesn't mean the death of innovation. Open source would be nothing without open standards, I've always held that belief. Without WC3 how could Firefox have fought IE? How could Chrome come into the picture to compete? Web browsing would be dead without open standards, which are arguably much more important than open source software.

  2. You are so right about the ARM world, Jeff - there is endless architectural variation in the systems already on offer. The bad news is that I expect it to proliferate, at least for a few more years.
    When I was first involved (my ARM binder is nearly 21 years old) it was a pretty long shot to sell a CPU design for incorporation into an ASIC with a bunch of other stuff to finish the system off. No semi fab? Crazy idea!
    Sure - there were Semi vendors who'd roll you an ASIC with their proprietary CPU stuck in one corner, but that was their ASIC technology, their CAD, and their CPU too. Even then there were scary problems in the area of testability. Ohhh yes!
    This is not to say it was a bad idea then, nor is it now. It's just that all these systems-on-a-chip have different guys adding stuff to the ARM core(s) they license.
    It's like the PC market before IBM - lotsa similar-but-subtly-different machines all running hand-massaged variants of MS-DOS, DR-DOS, you-name-it.
    Today, standard configurations like the nVidia Tegra and TI OMAP (hi there, JoZi) etc are helpful, but there's so much change already coming down the pipeline that it's bound to be turbulent for a while.
    Then the major players will emerge, the smaller ones gobbled up, standards will (hopefully) start to evolve and things might start to return to something resembling the x86 situation. But not the same, no.
    The good news is that in all this turbulence the agile of mind will thrive whilst the mighty dinosaurs of yesteryear are already trembling in their boots.
    I've been seriously struggling with the Debian Tegra stuff, so far! Probably just old age.....
    Check your PayPal Account, Jeff. Think I got mine working.
    Ben (aka Flymo)

  3. I don't know that it'll be so cut and dried. The IBM platform combined a de-facto standard base -- the PC/AT motherboard design, with 'good-enough' processing power in an open reference design that wasn't even intended to be that open but was forced open by the Phoenix/Compaq clean-room BIOS cloning -- with consumer-level hardware choice at the expansion slots and in the drive bays. Prior popular microcomputers with expansion room -- Altair/S100 and Apple -- were limited to 8-bit CPUs or their timing, and, unlike IBM who had antitrust concerns, IIRC Apple wasn't above going after cloners like Franklin in the courts. Other microcomputers with closed motherboards, even 16-bitters like AlphaMicro, stayed niche players because there was no standard way to improve your purchase from 'not quite' to 'meets my needs'; it was a black box deal.

    There are no expansion slots in current ARM devices -- how can there be, when the variations are at the chip level or on-chip? The commoditizing market forces that pushed even IBM aside when they tried to revert the PC/AT market to proprietary with MicroChannel just aren't there at the consumer level, and barely there at the manufacturer level.

    What I'm hoping will happen is a gradual filtering down of currently-NDA'd hardware-interface details into the current Linux soup of Maemo/LiMo/Meego/WebOS/your-flavor-here, cleaning up the configuration mess Linus complained about and commoditizing many of the components to the extent that their manufacturers don't have to worry about their parts and their details falling out of the main Linux git-tree. If and when vendors start noticing that having the ABI and register details looked after by kernel devs makes a design win more likely by mfgrs that won't tolerate NDA games when it hits them in time-to-market, we'll start seeing a concerted trend to post those details in someplace trustworthy, to wit, Linux kernel source.

  4. Sorry, I posted the wrong link earlier!


  5. the release of the Raspberry-PI might be the beginning of the end for this ARM madness.

  6. The manufacturers aren't interested in this: these are mostly low margin and/or short-life disposable devices (like the iStuff) with obsolescence built in. They definitely don't want buyers to be able to prolong their life, and they don't want to share in any more effort than they need to to get a system running on them (e.g. the arm driver mess in the kernel - much of it looks like it was hacked together just enough to work and then abandoned) least their competitors get an edge up in the market.

    Like most crap in this world: it's just about money. It would take a concerted push by something central like ARM to clean this up - Ti, Nvidia, Samsung, etc aren't likely to get together by themselves and are still busy creating proprietary hardware to differentiate themselves.

    Given a proper 'free market' it would eventually become a commodity with shared standards - since that will make it cheaper to bring devices using these chipsets to market. But markets aren't free and the costs are just passed on to customers (and ... they're not really all that much either).

    I do the only thing I can: I don't buy the stuff.

  7. Standards while helping software development, harm hardware development. x86 64 would be way faster or way lower power if it didn't support 32 bit. Arm as a computing platform is just emerging. Lets not lock this infant down quite so fast, will ya? Most Linux is held back by not supporting new x86 instructions, by not compiling with March. Let arm figure out who it is first and then make standards

  8. I think things are changing in that respect.


  9. Well seen.

    The first thought about that issue: does that happen due to the cutting cost reasons? I don't think so.

    The one who sells the device to the public, its the one who order it to the hardware assemblers. All ARM devices found in the shelves have a mark / model.

    x86 hardware may be found on sale as "white" brand. Its also very easy to buy each of its components and assemble the system. In this case, the only software in there it's the BIOS. That's the firmware and its embedded in the motherboard.

    I guess the problem is about the ARM's firmware.

    Right now very few people in the world do adventure on installing an O/S in their ARM hardware.

    Sometime, when (and if) user demand justify, I'm sure OEM's (Gigabyte, MSI, Asus, or what ever) will provide retail sale of those ARM devices, free of O/S....

    ... or more probable ready to O/S x, y, or z, to be installed.

  10. I don't think arm should have standards until they finish the 64 bit version of the design. The 64 bit version should NOT support 32 bit code, and rather dedicate it's full existance to 64 bit code. Ram quantities are increasing over time, and we don't want to be stuck in a stone age where we support 32 bit, when the average system has 16+ gigs of ram.

  11. "...lack of standards in the ARM world. A vast variety of hardware that all have different external components make this task difficult..." Change ARM to Linux and you see the problem vendors have.

  12. Well, I think the way out if OpenRISC/ OpenCores. Actually release a processor as an low-cost ASIC, and make a hundred or a hundred and fifty dollar tablet around Tizen, Bohdi, or Android.