ARM Is a Promising Platform But Needs To Learn From the PC

jbrodkin writes "Linux and ARM developers have clashed over what's been described as a 'United Nations-level complexity of the forks in the ARM section of the Linux kernel.' Linus Torvalds addressed the issue at LinuxCon this week on the 20th anniversary of Linux, saying the ARM platform has a lot to learn from the PC. While Torvalds noted that 'a lot of people love to hate the PC,' the fact that Intel, AMD, and hardware makers worked on building a common infrastructure 'made it very efficient and easy to support.' ARM, on the other hand, 'is missing it completely,' Torvalds said. 'ARM is this hodgepodge of five or six major companies and tens of minor companies making random pieces of hardware, and it looks like they're taking hardware and throwing it at a wall and seeing where it sticks, and making a chip out of what's stuck on the wall.'"

Comments

Re:ARM == shit.

[Anonymous Coward]

Don't stick it so far in next time.

Wait, what?

[MrEricSir]

"...tens of minor companies making random pieces of hardware..."

Has this guy never seen the PC hardware section at Fry's?

Re:Wait, what?

[Desler]

He's talking about CPUs, moron.

Re:Wait, what?

[kbolino]

All of which is, more or less, interchangeable. The Intel x86/IBM PC platform, despite its many flaws, has reached a stable point where there are well accepted and commonly implemented standards for the boot process, the storage formats, the hardware interfaces, etc. ARM, despite a "purer" and "simpler" instruction architecture, lacks much of this common surrounding infrastructure.

Re:Wait, what?

[Osgeld]

yea and that PC hardware uses the same cpu platform

with ARM well shit theres TI's flavor which doesnt play well with ST's version and lets not even get into the "arm based" stuff like PIC32

it is a mess, much like PC's in the late 70's and early 80's, they all have basic, but are totally incompatible

Re:Wait, what?

[thsths]

What is a desktop in the PC world is your SOC in the embedded world. It even comes with RAM and Flash (not on chip, but on package), if you want to.

The difference is that the PC environment has over a long time filtered down to a few typical devices for each type. Your network hardware is probably Realtek, or maybe Intel or an embedded AMD chip. You graphics card is NVidia, AMD or Intel. Your mouse does not matter, because it always talk USB HID etc.

In the ARM world, you also have standard components, but every integrator makes tiny (and usually pointless) changes that render them incompatible on the software level. Linus is right - this is neither necessary nor sustainable. It is one of the reasons that you can get software updates for a 5 year old PC, but not for a 6 months old smartphone.

Re:Wait, what?

[Anonymous Coward]

All of which is, more or less, interchangeable. The Intel x86/IBM PC platform, despite its many flaws, has reached a stable point where there are well accepted and commonly implemented standards for the boot process, the storage formats, the hardware interfaces, etc. ARM, despite a "purer" and "simpler" instruction architecture, lacks much of this common surrounding infrastructure.

Basically, ARM is to CPUs what Linux is to software.

Re:Wait, what?

[petermgreen]

The difference is that the PC environment has over a long time filtered down to a few typical devices for each type. Your network hardware is probably Realtek, or maybe Intel or an embedded AMD chip. You graphics card is NVidia, AMD or Intel. Your mouse does not matter, because it always talk USB HID etc.

And perhaps most importantly your main system bus is either PCI or something that looks like PCI to software and by accessing the configuration space of that bus you can read the device IDs of everything on it whereas with ARM the software is expected to know the complete hardware setup in advance.

Re:Wait, what?

[Anonymous Coward]

PIC32 is MIPS based.

Re:Wait, what?

[TheRaven64]

You're missing the point. He's not talking about add-ons like network adaptors, he's talking about fundamental core bits of hardware, like interrupt and DMA controllers, which need to be configured by the kernel before it can even bring things like serial ports online for a console.

Every PC, except some early Intel Macs, is capable of booting PC-DOS 1.0. It has interrupt controllers and device I/O configured in the same way and accessible via the standard BIOS interface. You don't get great performance if you use these, but you can bring up a system with them and then load better drivers if you have them. With ARM, every SoC needs its own set of drivers for core functionality long before you get to things like video or network adaptors. Oh, and on the subject of video, you don't even get something like the PC's text console as standard, let alone a framebuffer (via VESA).

Re:Wait, what?

[jedidiah]

It is NOTHING like computers in the 70s and 80s.

In the 80s, you had machines made out of standard 3rd party components. Your CPU was the same as the next guy even if he got his computer from a competing brand. This is why an Atari could emulate a Mac. The actual CPU was a particular part that everyone bought from the same place. This is why you can have versions of Linux targeting those 80s/90s era machines. A 68000 in one machine is the same as the next, or a 6502, or a 68030.

The old home computer landscape seems positively orderly by comparison.

Re:Wait, what?

[houstonbofh]

Not really. If I take a hard drive from my Ubuntu running PC, and stick it in a totally different PC, it will boot. And even X may come up. (And to cover the different level of your analogy, I can copy my "CryaonPhysicsDelux" folder from my Ubuntu system to a Red Hat system and it will run.) If I take a boot image from one ARM device, and stick it in another it will hang.

Re:Wait, what?

[Anonymous Coward]

Linux follows the standards for the boot process, power management, suspend & resume, plug and play, disk format, etc, and Windows uses voodoo to make it all work. Nice try buddy. The reason why a lot of that stuff took a while to work well in Linux is because most of it was implemented according to standards, standards which hardware vendors would ignore and mess around with (take a look at suspend/resume methods), but they worked fine in Windows and its drivers would use kludges to force these things to work (and not without a bunch of headaches).

Re:Wait, what?

[JDG1980]

The CPUs were standard, but little else was. Sure, the C-64 and Atari 800 both had a 6502-based CPU, but they also had different video chips, different sound chips, different and mutually incompatible disk drive formats and serial communications protocols, etc. One nice thing was that even though each company used their proprietary chips, they didn't feel the need to hide implementation details from users. If you wanted to know exactly what each register in the VIC-II chip did, it was right there in the manual.

Re:Wait, what?

[skids]

It's a complete mess and currently a huge barrier to development. You don't even have to get into coding for the kernel -- just getting a toolchain for your particular flavor of ARM is enough to turn away lots of developers. We're talking several DAYS spent figuring out how to produce a goddamn libgcc.a that has the correct endianness, MMU-or-not, and doesn't hose the system because it uses an undefined instruction to implement prefetch()... and then another night trying to figure out how to get that libgcc.a to also contain the symbols you need, and fondle elf2flt correctly, for you binary format, if you are nommu.

Now, if distros and gcc were to collaborate to clean that up to the point where there are prepackaged multilib cross compilers for aspiring embedded coders, then we'd have significantly more ARM developers.

Oh, and if you think demo boards have strange and unusual diversity for their SoCs wait till you see the inside of an inkjet printer OS. Try a flash card reader implemented with a sea-of-gates chip. Standard SDIO register set? Hah! You're lucky if a given device isn't hung off a gpio using a 32-bit register set that's hung off an 8-bit indexed register set that's accessed using a 16-bit access-width where the registers are spaced 64 bytes apart. Supposedly that's to shave pennies off the hardware cost, but I bet many more pennies were wasted on the development side trying to get the thing to work.

Re:Wait, what?

[LWATCDR]

And that is called inovation.
The orignal PC "Standard" sucked.
You had to asigne memory spaces, interrupts, and IO ports when you added cards. Not every card worked with every PC.
PC compatibility was hit or miss. The magazines would use Lotus 123 and Microsoft Flight Simulator as the benchmarks. If both of those ran then it was PC compatible. Of course if you bought anything but a real IBM PC or at you could still find software that didn't run.
Then you had the x86 CPU which also was terrible. Segmented memory was with us until the 386 and even that was register starved. The 68k line of CPUs was much better.
Then you had the companies that dared to make better computers than IBMs. Both the Zenith Z-100 and the Tandy 2000 where much better computers than the standard PCs of the time. They used the x86 but with better graphics. Thing is that they where not PC compatible.
And then you had to hope that your software would support your printer and video card if you got a better card then an MDA or CGA card. Hercules was a pretty safe bet.
We where stuck in PC hell for years even when better solutions where available like the Mac, Atari ST, and Amiga. The reason was simple. You developed software for seats and more people that bought software bought PCs.
We can use the same solution that finally made PC less of a steaming pile of dung. It is called an OS. You make a board and put an OS on it.
To make Linux better at embedded I would suggest that standards need to be developed for GPIO, SPI, I2C "sort of have that now", and CAN. That would solve so many issues on the applications side it wouldn't be funny.
For goodness sakes do not trap us into the Lowest Common Denominator hell that was the PC for way too long! USE THE OS!

Re:Wait, what?

[jedidiah]

Apple was the only one that had a "mutually incompatable" format. The rest not so much.

While there were a lot of custom chips, there were also a good number of stock parts as well. This included floppy controllers, IO controllers, and sound chips.

Now the bit about everything being documented is a good point. This is how it is that I am still somewhat familiar with the parts that were in my old machine. This probably made the 030 Linux versions a lot easier to deal with.

Re:Wait, what?

[Megane]

The CPUs were standard, but little else was. Sure, the C-64 and Atari 800 both had a 6502-based CPU, but they also had different video chips, different sound chips, different and mutually incompatible disk drive formats and serial communications protocols, etc

And that is probably the best analogy for the situation. The ARM CPU cores, while having quite a few differences from version to version, tend to be identical within a version, and are licensed as an entire unit from ARM, Inc. Very few companies (specifically Apple, thanks to the Newton era) have a license that allows them to mess with the core -- and even then they might not want to.

There is other stuff, at least in the current Cortex versions, such as basic interrupt control and probably the MMU, that is also part of that core (I work with Cortex M3 and no OS these days, so I really don't know about MMUs). But everything else is unique to the chip maker, even for the same type of interface. ST's I2C controller will be completely different from Cirrus's I2C controller, etc.

And FYI, the only reason an Atari ST could run MacOS was because the only assumption of MacOS in those days with respect to graphics was a 1-bit deep, 8 pixels per byte, bitmapped display. The Amiga also used a 68000, but it had a rocket science blitter thingy, which is why there wasn't a similar ability to run Amiga software on an ST.

Re:Wait, what?

[Luckyo]

In a nutshell, essentially everything in and out of PC is standardized, and when it's not, drivers usually provide abstraction to some standardized layer to ensure compatibility. This is true, and is probably the point you're trying to make. But it ended up coming pretty badly mangled.
In fact the sheer size of falsehood in your claim is astonishing. The entire point of PC platform is that it supports a massive amount of different hardware configurations that all work with the same x86 (amd64) code.

Networking hardware vendors are dime a dozen. There are hundreds of them. All of them work in the OS on their own x86/(amd64) drivers. Graphics market has shrunk somewhat, but just a few years ago there was about 20 vendors. All of whom worked. Most still do. Mice, and controller device numbers, as well as their unique solutions are insane - we have keyboards, mice, special keyboards, special mice, wheels, pedals, joysticks, various control interfaces for variously impaired people, various touch screens... The list is almost endless.

How you could claim that things have "filtered down to a few typical devices of each type" on PC and get +5 informative is beyond me. Most PCs certainly have the usual peripherals, but amount of specialized, WORKING components and peripherals in PC world that can just be hooked in, have drivers installed and work in whatever exotic combination you want outnumber any platform by far. That's one of the most important attractions of the platform, as well as one of its harshest features to program and test for.

That's the difference: with ARM, if you design software, you need to know the hardware you're designing it for. With a PC, you just design x86/amd64 software mostly caring about OS platform, and you start caring about hardware only when you optimize. Hell, in many cases you can even make it work under all popular OS's, porting your software to windows, mac os and linux with minimal hassle. Not so with ARM.

Re:Wait, what?

[Osgeld]

so your saying (my little linux troll) that a mos 6502 , motorola 68000 and lets say an intel 8008 are all the same

what the fuck man, do you drink heavily before stalking me?

Re:Wait, what?

[Osgeld]

my bad, LM3S9B92 then

Re:Wait, what?

[Rob Y.]

It almost brings to mind the Linux desktop situation. Sure the underlying engine (linux kernel, drivers, etc) is the same across distros, like the basic ARM processor instruction set is the same for ARM. But all the glue that holds a system together is different. Choice of desktops, sound systems, desktop interprocess communications. Every distro puts together a Linux 'system' from the Linux kernel, X11 and various combinations of these other software components the way every ARM box generates a system from an ARM processor and various other hardware components.

At least it seems like Linus understands the advantages of standardization.

And all the 'cruft' required to run PC-DOS 1.0 doesn't seem to hurt the performance of all that PC hardware. The software analog would be the code required to maintain backward compatibility at least across a given set of tools.

Re:Wait, what?

[mikael]

ARM descended from Acorn Computers, who provided the Archimedes computer along with a RISC OS. They seem to have bought out every possible semiconductor design group and merged them together.

Remember those times in the mid/early 1990's. As mentioned, there was a vast variety of different consumer PC's, along with experimental operating systems like TAOS - a JAVA like system with cross-platform compilation and dynamic linking.

Graphics boards were upgraded every six months as they are now: CGA, Hercules, EGA, VGA, SVGA, accelerated SVGA, and so on..
Back in the 1980's, everything was aimed to be Hercules compatible.
From an Ad Lib sound card manual:

Ad Lib Septembre 1987

          Because of compatibility problems between Compaq's Deskpro 86
          and Hercules graphics card, our software cannot make use of a
          mouse unless you upgrade Compaq's BIOS to a newer version.

Re:Wait, what?

[Anonymous Coward]

Apple was the only one that had a "mutually incompatable" format. The rest not so much.

Oh, bullcrap. The most successful 8-bit platforms were Apple II, Atari 8-bit (400/800 etc), and C64. All of them had mutually incompatible disk formats.

While there were a lot of custom chips, there were also a good number of stock parts as well. This included floppy controllers, IO controllers, and sound chips.

Later on, perhaps. During the rise of 8-bit home computers, no. Stock parts for these functions didn't come about until there was an industry to demand them.

Now the bit about everything being documented is a good point. This is how it is that I am still somewhat familiar with the parts that were in my old machine. This probably made the 030 Linux versions a lot easier to deal with.

I think you overestimate the documentation. I'm pretty sure you're an Atari troll from way back who's still butthurt that Apple won, and I regret to inform you that Atari never documented its hardware. Not in the ST era, and especially not in the 8-bit era. Most of the 8-bit era took place under Warner ownership, which saw outside developers as a threat to take market share away from Atari's internally developed games. I still have a popular 3rd party Atari 8-bit programmer's reference manual written by a guy who spent a lot of time reverse engineering the chip registers.

It was easier to find information out about the ST's chips simply because many of them were off the shelf chips with easily obtained documentation. However, as with the 8-bit series, Atari released no information about the custom ICs.

Re:Wait, what?

[WorBlux]

Actually all that cruft does slow things down in a major way when you try to initialize hardware. Compare the times of Coreboot --> Linux to BIOS --> bootloader ---> linux.

Anyways standardizing some of these component's wouldn't be a bad idea, say the ARM group providing a few standard modules than can be leased with the Core designs.

Re:Wait, what?

[rufty_tufty]

This like Linus is spoken by someone who cannot have done any ASIC/embedded development.
There are standard graphics pipelines but you will integrate them onto your SOC with direct access to your SDRAM. This removes any standard bus architecture. You may even write your own 3D pipeline.You will probably write your own SDRAM controller. You will add your own peripherals. Why do this rather than plug in standard components? Well if you just stick off the shelf stuff together then how is your product any different from your competitor? You can just build lego and there's nothing wrog with that, but if you are clever then you can get rid of inefficiencies in the system. that is engineering. No you are in business because (for example) you think you can make a better 3D pipeline than ATI, or perhaps you think you can come up with a better bus infrastructure than the ARM standard. Maybe you want to even customize the ARM processor itself? These are not pointless changes, they may be changes you don't understand but that does not make them pointless. Let me take an example I am allowed to talk about: is it better to do your 3D pipeline with a wide array of low clock speed processors that are shared with your imagining pipeline or to have different processor architectures for each function or pipelines hardcoded to the exact operation of each function? There is no good answer and a full spectrum of solution between each possibility. A low cost design will probably be better with shared general purpose hardware a high performance will be better with many tailored processors.

The whole point of ARM is that it is used in the embedded world. The whole point of the embedded world is that it is a (semi-)custom design for that application. Targeting Linux-arm for a router is a very different problem (in hardware terms) from a thermostat, to a games console to an e-reader to a mobile phone. A different problem requires a different solution. In a PC you just need to provide grunt, previous posters have mentioned PCI enumeration, and that's great, but in embedded you can't waste the time nor effort nor power nor hardware on this process because it is not _needed_ it'd be a lot easier to include it but you often have to remove it because of its cost. This is a world where your customer won't let you have even 5% left on the table for overhead, so burning silicon area and power in the name of commonality is a no-no (at least you have to do the trade-off between software effort and hardware cost).
Even if you limit the problem to mobile handsets why should I burn 60% more power* by using an off the shelf hardware video encoder in order to make things easy for Linus? Would you rather do a tricky software merge or have a mobile phone that has twice the battery life? Without the ability to tailor the hardware to the problem you will waste area and power and also limit innovation.
Let's face it, it would be easier to not have graphics card acceleration, or RAID accelerators or DMA engines or any form of CPU offload, but that's the world we live in.
Now I grant you that in the Linux situation making things cheaper by this kind of customisation makes things harder for the kernel developer, but that's the nature of the problem. If they don't want to play in that field then that's fine, the GPL lets you do that, but you have to be able to customize architectures to play in the embedded world it's that simple.
* I have pulled these numbers out of the air, I don't want to get into trouble for even trying to do anything near confidential.

Re:Wait, what?

[arglebargle_xiv]

And perhaps most importantly your main system bus is either PCI or something that looks like PCI to software and by accessing the configuration space of that bus you can read the device IDs of everything on it whereas with ARM the software is expected to know the complete hardware setup in advance.

Amen to that. It seems like every vendor's pet ARM variant, and every stepping of every variant, has tons of semi-custom value-add features that they have to add because if they didn't differentiate their variant from everyone else's, you might buy the other guy's device. There's usually no way to tell what's present and what isn't, so you end up creating these complex expert systems that "know" that if you're using vendor X, product Y, stepping Z, then this set of additional functionality is available. Anything that isn't present in your ruleset (i.e. every ARM device that you don't have complete specs for in advance and can test the functionality with) can't be used, and every time there's a new stepping or device release you can't use any of the additional functionality until you've researched it and updated your config.

What the situation reminds me of most is the PC hardware market in the 1980s (everyone does their own oddball hardware and interface) but without the ability to dynamically load a device driver or TSR to talk to it. Unless you develop for one hardware platform/device type and target that in depth, you can never take advantage of all the extra functionality present in most of these devices. Even ARM's primitive attempts at defining HALs are so minimal as to be mostly useless, and half the vendors don't support them anyway.

Re:Wait, what?

[arglebargle_xiv]

There are standard graphics pipelines but you will integrate them onto your SOC with direct access to your SDRAM. This removes any standard bus architecture. You may even write your own 3D pipeline.You will probably write your own SDRAM controller. You will add your own peripherals. Why do this rather than plug in standard components? Well if you just stick off the shelf stuff together then how is your product any different from your competitor?

That's exactly the thinking of the device vendors that's got us into the mess we're in now. It's fine if you're a device vendor, it's OK if you're a manufacturer who can ship 100M units with exactly one ARM-based ASIC in it that'll never change in its lifetime, and it's a nightmare if you're doing anything else. For example to do something as basic as add TCP offload on ARM ASICs to our stuff we'd have had to add custom code for every single fscking vendor's bizarro TOE concept. In the end we did it all in software, completely ignoring whatever hardware assist the networking functionality could have had, and offered customers the chance to add custom support for any TOE hardware if they paid for it. So far, zero have taken us up on that. We're doing virtually all the networking in software because that's the only thing that's guaranteed to be the same across all devices.

So it depends on your business model. For the selfish model, "no-one exists but us", it's fine to use a ton of non-standard custom functionality. For a universalist model, "we're part of an overall ecosystem", you need to be a team player. ARM isn't a team, it's the Balkans, a bunch of stuff that looks more or less the same on the surface but that's deeply divided by endless numbers of ludicrous nitpicky differences that you need a PhD-level depth of knowledge just to understand..

Re:Wait, what?

[NotQuiteInsane]

The PIC32 isn't ARM-based. It's MIPS32-based.

The Philips/NXP LPC series is (for the most part) ARM-based though. ARM CPU core tied to custom peripherals (though as I understand it the UART is a stock-standard 16550)

Re:Wait, what?

[LWATCDR]

No graphic cards where not upgraded very six months.
CGA 1981 http://en.wikipedia.org/wiki/Color_Graphics_Adapter
EGA October of 1984. http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter
VGA 1987 http://en.wikipedia.org/wiki/Video_Graphics_Array
Hercules was in the 1982-83 area but they where not a "Standard" card but where well supported but also only mono.
As you can see before the OS offered drivers and abstracted the hardware change was slow. You really had to wait for IBM to set a "standard" or you had to hope that your software supported your hardware.
The thing is that we don't need standardized ARM hardware. What we need is for the hardware makers to write drivers and or document them and support FOSS development.
It isn't that hard. Look at the Beagle board and the Gummstix as examples.

Re:Wait, what?

[rufty_tufty]

Well put yourself in our shoes.
You've got to remember an ATI chipset is not a standard, OpenGl is the standard, why shouldn't I be able to develop my own pipeline as long as it complies with the standard?
SDRAM is a standard, ARM's implementation of their controller might be targeted for their processor but not for the 3D pipeline you're building, so by building your own you can do better. Trust me an arm processor and 3D pipeline need very different things from an SDRAM controller. Why shouldn't I be able to make a better controller as long as it fits the memory standard and I provide drivers to allow the OS to use it.
Granted on things like the HDMI interface I'm never going to be able to open the driver source code to you because there are secrets in there I'm legally not allowed to give people (HDCP keys spring to mind).
Should I not be able to do those things? Is it really a better world where there is the one true architecture and no others are allowed?
Maybe it is, maybe Linux cannot cope with the things I want to do. Fine I know I'll branch the code, that's the great thing about OSS I can branch if I need to and do my own thing. But that's how the arm code started and then they tried to pull it back into the main stream. And the cycle starts again...

Re:Wait, what?

[CheerfulMacFanboy]

While there were a lot of custom chips, there were also a good number of stock parts as well. This included floppy controllers, IO controllers, and sound chips.

Later on, perhaps. During the rise of 8-bit home computers, no. Stock parts for these functions didn't come about until there was an industry to demand them.

Actually they were available early on - they just cost dozens of dollars just for a floppy controller. That's why most mass market computers used self-made, cheaper solutions, where the design cost was easily outweighed by the cheaper construction.

Re:Wait, what?

[mikael]

Maybe it was just me then - got my first PC in 1989 (20MHz Dell 310), got an upgrade to a 256K Paradise VGA board about 6 months later, moved onto a TIGA board with a few Megabytes memory and 32-bit framebuffer another 6 months later. Another six months later, I've got employment using a custom PC.

Had great fun programming the VGA directly; doing fun things like changing the character set, trying out Mode X from Dr. Dobbs, with 256 colors and page flipping, implementing scrollable viewports, palette editors, bitmap font editors, a 256 color version of the BGI drivers.

Fascinating reference to the Beagle and Gumstixx boards. I'm amazed by how far along embedded systems with graphics chips/OpenGL have come along.

Re:Wait, what?

[LWATCDR]

By 1990 we where already 9 years into the PC lifecycle. In those ten years we gone through 4 generations of mainstream video standards, three generations of CPUs, and where on the third generation of Windows, and frankly the first usable one but still version three." It was well after the standard was set. The thing was that even with all that development on the "standard". It still sucked to high heaven.
The Mac, Amiga, and Atari ST where all still better and they where all from the mid 80s. If you adopt a standard too soon you are often stuck with it for a long time the PC is a great example. I often jokes that I hated to use PCs because they where more primative than my oldcommodore 64 or Amiga.
Yes the Beagle and Gumstixx are both very interesting. Most applications will run on both just fine. The trouble is when you want to do something with GPIO and or SPI. As I said for those we need a standard interface. With that you could add a USB to SPI bridge to a PC and do your development on a PC while accessing all the hardware. Same thing with GPIO, CAN BUS and so on. For GPIO you could always use a printer port if you are on a desktop.

Re:Wait, what?

[mikael]

I always remember that time in 1986 when our lab PC's had CGA graphics,EGA was high-end, and even the Atari 800XL could do 256 colors using some HBI's. All the artists I knew, used Amigas for rendering characters and levels.

Re:ARM == shit.

[AnujMore]

returns value "false"

That's the trouble with a monolithic kernel

[Animats]

The embedded world doesn't have much trouble with this. For QNX, there's the kernel, which is the same for all CPUs with the same instructions set, and a "board support package", which has the driver programs for a given board or variant.

Linux is a monolithic kernel, and so it has to be hacked all over the place to deal with architecture variations. Linux lacks a clean conceptual model of operating system vs. board support.

Re:That's the trouble with a monolithic kernel

[denis-The-menace]

You mean like a HAL in Windows NT.

Now I know where MS got the idea from.

Re:That's the trouble with a monolithic kernel

[Osgeld]

I have 2 arms sitting on the side of the bench now that are incompatible instruction sets ... so back to square one I guess

Re:That's the trouble with a monolithic kernel

[Anonymous Coward]

The problem is that micro kernels have always been harder to develop and slower(if not done carefully). And not all "board features" can be separated/exposed from/to the kernel easily when done externally.

For instance, paging and memory management is usually something that would go in the kernel, even a microkernel. Do you know how many different ARM MMU interfaces there are, and also how many ARM processors don't have an MMU, or that implement only a subset of some other MMU. And then there is the dual-core processors now as well. I wonder how many different interfaces there are for controlling both multiple ARM cores or ARM processors.

Basically, ARM is a cluster fuck for OS development. They need some form of standardization if they ever hope to get widespread OS support. Linux is probably only supported by most boards because the board manufacturers submit patches to the Linux project. By widespread, I mean each board supporting a minimum of 3 different operating systems, for instance Windows, Linux, and something proprietary or a BSD.

Re:That's the trouble with a monolithic kernel

[Anonymous Coward]

I kinda wish MIPS had done a better job at pushing their embedded cores. If MIPS had won we would already have a full, stable, 64-bit ISA from which to build servers.

Re:That's the trouble with a monolithic kernel

[Relayman]

Based on your comment, Linux should add an abstraction layer that is resolved at compile time (for optimum performance) that isolates the various flavors of ARM from the Linux kernel.

You make it sound like the best and brightest computer jocks aren't working on Linux for free. Imagine that...

Re:That's the trouble with a monolithic kernel

[Jonner]

The embedded world doesn't have much trouble with this. For QNX, there's the kernel, which is the same for all CPUs with the same instructions set, and a "board support package", which has the driver programs for a given board or variant.

Linux is a monolithic kernel, and so it has to be hacked all over the place to deal with architecture variations. Linux lacks a clean conceptual model of operating system vs. board support.

Linux supported many architectures before ARM, so Linus's complaints don't come from a purely PC mindset. You also seem to be ignoring the fact that Linux is and has long been a major part the embedded world. How many smart phones run QNX?

Re:That's the trouble with a monolithic kernel

[Yvan256]

And bad news for Windows NT users named Dave.

Re:That's the trouble with a monolithic kernel

[Anonymous Coward]

I have 2 arms sitting on the side of the bench now that are incompatible instruction sets ... so back to square one I guess

Funny, my two arms seem to have incompatible instruction sets too...especially when I try to be the drummer in RockBand.... ;)

Re:That's the trouble with a monolithic kernel

[Entrope]

Microkernel versus monolithic kernel has nothing to do with board support packages.

Linux has the equivalent of "board support packages" -- they can be as small as one file, but are more often just a handful: a C file that describes memory and I/O mappings and other peripherals that cannot be safely detected at runtime, sometimes a default configuration (defconfig) file, and maybe some other pretty small driver-like files that manage some of the mess that Linus was talking about. (For example, the BeagleBoard has three C files: one to define the board, one to manage LCD video configuration, and one for audio setup; it shares a defconfig with every other board using an OMAP2/3/4 CPU.)

That is in sharp contrast to my experience with commercial RTOSes, where a BSP might consist of a dozen C source and header files, plus another half-dozen configuration files. For the boards I have used, Linux has the smallest set of board-specific files, a microkernel RTOS has the next smallest, and a Unix-based RTOS has the largest. Linux doesn't call its board-specific file sets BSPs because they are (a) too small to really call a "package" and (b) not controlled and shipped separately. (Linux is not about locking down what the end user can do, so there would be no point in having BSPs for officially supported boards.)

Re:That's the trouble with a monolithic kernel

[FrangoAssado]

Exactly.

The problem is not that adding support to a new board in Linux is too hard, in fact, it's almost the opposite. There are already tens of slightly incompatible boards to support, and every time a company makes a new one, they don't even try to stick to any standard (not that there even *exists* a real standard), since it's very easy to just add new code to Linux. See this LKML thread for Linus's description of the problem from some time ago.

Using a microkernel doesn't help at all; you still have to code for all of the slight incompatibilities, regardless of whatever differences in logical organization.

Re:That's the trouble with a monolithic kernel

[GooberToo]

and so it has to be hacked all over the place to deal with architecture variations.

Bullshit. Linux abstracts such details though various standardized functions and macros. If you've bothered to pull your head from your ass and take even a quick look at the Linux source tree, you can clearly see the architecture variants are cleanly broken out.

Not only is your post NOT "Interesting", as was modded, it is factually, "Troll".

Re:That's the trouble with a monolithic kernel

[Anonymous Coward]

nope, even the kernel's core assembly instructions for various ARM instruction sets have to be different too. You're talking out of your ass, your employer has the "best and brightest" shortage.

Re:That's the trouble with a monolithic kernel

[Anonymous Coward]

You mean Dave Cutler?

Re:That's the trouble with a monolithic kernel

[Yvan256]

Nope, Dr. Dave Bowman.

Re:That's the trouble with a monolithic kernel

[Megane]

My arms are incompatible because they have thumbs on the opposite sides of the hand. I have to wear a different glove for each one.

Re:That's the trouble with a monolithic kernel

[unixisc]

As far as 64-bit goes, I'd say their opportunity is still open. Once ARM has a 64-bit version, it'll be gone.

Re:Wait

[Anonymous Coward]

No, but Slashdot is saying you should practice reading comprehension.

Different for embedded rigs than PCs

[Anonymous Coward]

They're not trying to cut corners for the hell of it, but for performance, power usage, and other actual engineering reasons.

You just cant build smartphones and tablets with that same common architecture, or else you're adding too many chips and circuits you don't need.

It's no big deal that PC's ship with empty PCI slots and huge chunks of the bios and chipset that are never used but rarely. (Onboard raid, ECC codes, so on and so on), but when you're trying to put together a device as trim and minimalist as possible, you're going to end up with something slightly different for each use case.

Re:Different for embedded rigs than PCs

[hedwards]

He's acknowledging that, but at the same time discounting the advantages of having a minimalist option. I don't see any problem with having a heavier duty ARM available, but suggesting that there's not value to having chips that have just the necessary circuits is silly.

Re:Different for embedded rigs than PCs

[RobertLTux]

there is a difference between %feature% being present/absent and %feature% having 30 different implementations (of which 12 are actually hostile to others).

when you have to have a venn diagram with PLAID as one of the circles then you are in trouble.

Re:Different for embedded rigs than PCs

[NoNonAlphaCharsHere]

This whole article is bullshit. Is everyone forgetting the varying instruction sets of the 386, 486, Pentium, Pentium 2-4, Xeon, x86-64 etc., etc. Plus all the millions of Northbridge and Southbridge chipsets from Intel, Via, etc., plus all the different busses through the ages, plus 92 different kinds of temperature monitoring, USB, ATAPI, ACPI...

And we're badmouthing ARM for being a constantly moving target? And that manufacturers are throwing shit at the wall? Huh???

Re:Different for embedded rigs than PCs

[UnknowingFool]

Unfortunately one of advantages of ARM is that the chip maker can heavily customize what is on the SOC. Most of them don't mess with the core. I don't think that the different makers are intending to have hostile features but given time constraints for development, they can't check with other companies (some of them competitors) to see if there optimization hurts others.

Re:Different for embedded rigs than PCs

[Pentium100]

And yet, you can run, say, DOS on all of those computers. Critical devices will support a "generic" instruction set. Any VGA card will support standard VGA instructions, disk drives can be accessed using standard IDE interface (SATA controllers can emulate it). SCSI drives can be accessed using INT13h, the controller BIOS takes care of it. Keyboard/mouse use one of the few interfaces (and USB can emulate PS/2).

Now, when you get the basic system running, you can load drivers to access all of the features of the hardware (for example, different resolutions of the VGA card).

For ARM you have to recompile the kernel for most of the chips and boards for it to even boot. So, how would you create a way to install an operating system from me media not using another PC?

Re:Different for embedded rigs than PCs

[hitmark]

I think perhaps the biggest complaint is that ARM lacks a unified bootstrap and hardware bus. As in, there is no BIOS like on the X86, nor is there a PCI or similar that one can query and get a dump of device ids. So for a lot of the SoCs you basically need to know what is on there before you start sending signals.

Re:Different for embedded rigs than PCs

[Wesley Felter]

Not sure how this is insightful.

They're not trying to cut corners for the hell of it, but for performance, power usage, and other actual engineering reasons.You just cant build smartphones and tablets with that same common architecture, or else you're adding too many chips and circuits you don't need.

A common firmware interface (like BIOS, OF, or EFI) and something like a device tree doesn't require extra chips. At most maybe it's a few KB of flash.

Re:Different for embedded rigs than PCs

[Anonymous Coward]

"Most of them don't mee with the core"? Talking from personal experience, each time we get a new SOC, we have to recompile the bootloader code because every new SOC changes the boot address. All x86 boots from FFFFFFF0. That's just one arbitrary number, and yet the ARM manufacturers can't bother to pick the same reset vector.

Re:Different for embedded rigs than PCs

[rufty_tufty]

Right, because do you want to boot your router from ROM? Or your IP phone from flash attached over what will later be GPIO? or your Mobile phone from SDCARD. Your tablet an embedded SSD, your MP3 player from its flash chip over custom interface*, your set top box from its hard drive? What if you have one processor booting another, what if it needs to do a first stage loader from ROM and then grab the image over ethernet (using your own ethernet implementation of course). What if it's not ethernet but SPI?
So you come up with this Frankenstein of a common bios and it takes $2 worth of flash to store it in, well if your entire SOC only costs $2 then what do you do? Cut out the bits of the bios you don't need? Then you're back to square 1 of a custom bios.
PCs don't have this problem because they will always** have a keyboard, a mouse, a screen, RS232, a hard drive, a floppy drive, USB etc
* And of course you need a custom interface because the standard one the kernel supports bit-bangs the operation for maximum commonality, but that's not quick enough for your customer requirement. So you write a bit of hardware to do that for you. You could put in a compatibility mode but that will cost you 0.1c of silicon per chip an multiplied by the hundreds of thousands you plan to sell of this chip it soon adds up to be worthwhile.
** Yes yes I know, "Keyboard not found press F1 to continue", this is not true for servers and historically there was not always a hard drive never mind USB but you get the idea. An embedded device however has no concept of common requirements of hardware. Also while PC's have always been very cost sensitive very few PC historically sold were targeting a device cost of a few dollars so you have to cut something...

Re:Different for embedded rigs than PCs

[AmiMoJo]

That is the reason we have drivers. Unfortunately the ones supplied by embedded manufacturers tend to be kinda crap in my experience. There is also a lack of solid APIs for many embedded system features, where are desktop ones are quite comprehensive and mature now.

At the place I work some guys are making a hand held logger using Windows 7 Embedded and the support from the manufacturer is terrible. Took two weeks and sending test code to their office in Israel just to get the vector processing features of the CPU to work. We changed LCD and had to change the screen resolution which meant re-building the OS and then discovered that the old LCD won't display the lower resolution at all so the prototype had to be modified in a hurry. We are still unable to read hardware buttons on the damn thing...

Note to self:

[sgt scrub]

Goals for Friday.
1) play all pink floyd albums in a continuous loop.
2) make bubbly gurgle sounds with my "sandwich".
3) contemplate "making a chip out of what sticks on the wall".

Sounds like Linux

[Anonymous Coward]

This actually sounds a lot like the comparison between Linux (ARM) and Mac OS X / Windows (Intel CPU).

Companies trying to support Linux with closed-source software struggle with a hodgepodge of distributions, kernels, and compilers.

IOW

[CheerfulMacFanboy]

"ARM should be more like my previous employer Transmeta".

Re:Wait

[denis-The-menace]

Maybe some coordination to make sure that similar instructions work the same way across all ARM CPUs.

Openness?

[Baloroth]

Is Linus Torvalds (implicitly, at least) criticizing ARM because it is open and therefore anyone can create their own version of it? As opposed to x86, which has a restricted licensing set (AMD/Intel/Via... Via still exists, right?)? Because that is, AFAICT, exactly why ARM is so varied: anyone can roll their own. With the result that many do.

Kinda ironic (and I do mean *ironic*) that the creator of Linux would be complaining about this. I guess he is finally discovering why, in some cases, a regulated and restricted environment can be good (note: if x86 was a monopoly, I would not be saying that. But AMD and Intel are fierce competitors, so it isn't at all monopolistic). Open environments often become "hodgepodges" and lend themselves to non-standardization. Closed ones don't (well, they can, but generally they don't. Definitely not as fast as an open one) and can be easily standardized (witness how Intel accepted AMD's x86-64 set for consumers over their own I64 system). The result is, in the case of CPUs, good for consumers.

Note: I am note proclaiming the virtues of proprietary systems, or claiming they are better than free and open ones. Just pointing out the irony of the situation.

Re:Openness?

[RyuuzakiTetsuya]

Linus doesn't have the RMS/ESR stick up his ass about "open." Linux was built out of necessity because no good x86 based *NIX or BSD was available. if HURD got off the ground, Linus wouldn't have bothered with Linux.

Re:Openness?

[Jonner]

Is Linus Torvalds (implicitly, at least) criticizing ARM because it is open and therefore anyone can create their own version of it? As opposed to x86, which has a restricted licensing set (AMD/Intel/Via... Via still exists, right?)? Because that is, AFAICT, exactly why ARM is so varied: anyone can roll their own. With the result that many do.

ARM is not any more "open" than x86. To sell chips implementing modern versions of either instruction set, you must obtain a license from at least one company and nothing prevents you from extending that instruction set. Many companies have implemented (and often extened) each set over the years, though there are fewer implementing x86 now than ARM. There are probably fewer implementors of x86 because it is much more complex.

I think Linus is criticizing the lack of a common platform surrounding ARM rather than the instructions themselves. The instruction set of x86 chips has grown a lot, especially with x86_64, but the way you boot a PC hasn't changed much for example.

Re:Openness?

[Anonymous Coward]

Actually, the stick up Stallman's ass is about "free", not "open".

Re:Openness?

[Matt_Bennett]

Open? How is ARM open? ARM is a very popular but *licensed* core that you must pay a good deal of money to license. According to the Wikipedia article on ARM, in 2006 it cost about $1,800,000 per license.

Re:Openness?

[Seyedkevin]

I don't understand why people keep making the misconception that "open" means "incompatible is good".

Yes, there are people who make new standards. Perhaps because they felt it logical, impractical to adhere to pre-existing standards, or maybe they made a mistake. But the gross majority of open source is about implementing standards in a different ways.

When open source applications *do* make new standards, it's very common for the said standard to have a nice little library so that anyone else can reimplement the standard. This isn't like proprietary software where someone has to reverse engineer the program and go through obfuscation (see skype) for another application to be able to communicate, and, in other words, contribute to the universality of the standard.

But here, we're talking about hardware. You can't change hardware. You could say that every arm chip is like a different standard in which Linux is supposed to abstract away, which is redundant effort and a hassle for everyone. Openness, I think, is about allowing others to be able to contribute and standardization helps greatly to let this happen.

Heck, look at POSIX. It's done one of the most good for FLOSS since it allowed contributions from all compliant operating systems to contribute to one another.

It's *not* ironic because openness strives on standards.

Re:Openness?

[JackDW]

Actually it is the other way around. The x86 platform is mostly based on open standards. There are more 486-compatible clones than you may realise. ARM, on the other hand, is strongly proprietary. There are no clones at all. The ARM fragmentation has occurred because of a lack of open standards - while the PC guys were standardising PCI, USB and VGA, every ARM licensee was reinventing the wheel to give their own SoC the features that nobody else had. While the core ISA is always the same, the system architecture is not.

When ARM CPUs were only used for embedded systems, this was fine, because each vendor could provide a BSP for each supported OS. Now that ARM CPUs are being used in general-purpose computers like Windows Phone 7 and Android handsets, the fragmentation has become an issue preventing users from loading alternative firmware. Clearly, this is a concern for Linus Torvalds (and Linux supporters who understand the issue) as it causes pain for kernel development and makes it essentially impossible to produce a single OS that could be installed (say) on any ARM-based smartphone.

Re:Openness?

[gabebear]

Licensing ARM is trivial, x86 is more or less impossible to license. The cost you are quoting is the average license cost, Wikipedia also breaks it down to a per-device cost of $0.11 per device.

Re:Openness?

[GooberToo]

Open? How is ARM open?

Probably because there are royalty free, freely available ARM designs available for use by anyone. Its not their leaded edge designs, but ARM is freely available.

Re:Openness?

[yuhong]

ARM is not any more "open" than x86. To sell chips implementing modern versions of either instruction set, you must obtain a license from at least one company and nothing prevents you from extending that instruction set

Yes, but I think ARM is much easier to license than x86.

Re:Openness?

[zixxt]

Open? How is ARM open?

Probably because there are royalty free, freely available ARM designs available for use by anyone. Its not their leaded edge designs, but ARM is freely available.

Until ARM is like say OpenSPARC or LEON where you can get the source code of the chips and logic for free under the GPL or some other open source license, without the cost of paying any fee, then ARM is anything but free available.

Re:Openness?

[Arlet]

Or, more likely, the $1 million+ license fees, and the royalties per core are not a big obstacle for dozens of different licensees.

In return for the license, you get a high quality core for your ASIC, so that's worth it for a lot of customers.

Re:Openness?

[Matt_Bennett]

There are? OpenCores has one beta VHDL implementation (it hasn't been updated since December 2009) that I can find with a quick search- everything else I find leads to a dead-end. I don't see any ARM cores listed on opencores that have been ASIC proven.

While there may be some designs available, I don't think any of the ARM implementations that are in the Linux kernel are based on an open core. If you are aware of an open core that can run Linux, I would appreciate a pointer.

Beyond anything else, ARM is a trademark used to refer to one of a bunch of cores that the ARM Holdings company have made. Saying you have an open ARM core is only scratching the surface of what the part actually does- for example the first ARM core (ARMv1) had no cache, no MMU, and ran (typically) at less than 2 DMIP- not something you'd really have a hope of running the Linux kernel on.

Re:Openness?

[zixxt]

x86 is not open at all. It is one of most closed archs still around and there's less than a handful of companies license that can make x86 cpus, and Intel is never going to be selling you a license. One cannot compare the x86 arch to other arches such as Power(PC), SPARC, and say that x86 is open unless you mean open means closed. http://en.wikipedia.org/wiki/Comparison_of_CPU_architectures look at the table for open and/or Royalty-free

Re:Openness?

[Matt_Bennett]

I'm 100% certain that if ask ARM to license 10, 100 or even 1000 cores at $0.11 per core, they won't even talk to you. Developing a device around an ARM core is expensive and has high start-up costs. Remember that $1.8M is the average cost of a license, some people pay more, some less, but ARM holdings is a for-profit company, not a charity. They are out to make money. It is not in their business interests to license the core to you if they aren't going to make money off of it, and on average, they made $1.8M per license (in 2006).

Re:Openness?

[Anonymous Coward]

Indeed; the ARM was originally designed precisely because Intel *wouldn't* license their processor designs for modification in the way Acorn wanted.

Re:Openness?

[JackDW]

Well, it is certainly more open than ARM, and that was the point I was making.

Secondly, as I said, there are many 486 clones. It is only around the introduction of Pentium Pro and MMX that the ISA began to be patented. Clones typically omit these instructions.

Re:Openness?

[Darinbob]

The problem I think is that the abstraction of the CPU is seen differently in the ARM community from the x86 community. So Linus is frustrated that the ARM side doesn't see the CPU as "processor plus memory management plus bus management plus system control".

ARM is going after a different market than the typical desktop/server and so has different needs. Whereas Intel, AMD and others want to be very compatible and mostly plug compatible at the software/OS level so that you don't have to have different versions of Windows or Linux or MacOS to support them. ARM is used quite a lot in custom products, it gets included as part of larger ASICs, etc.

Linux can support PowerPC and x86 and Sparc and so on. If it can handle all that it should be able to handle ARM. You can't just shove all of ARM in one directory though and expect it to be as simple as a highly standardized product. Similarly there are embedded x86 devices that can not use the standard x86 Linux port either because they're not PC compatible.

Re:Openness?

[Anonymous Coward]

Actually, RMS has a pretty big stick up his ass about "open", and people supporting it when they should be supporting "free".

Re:Openness?

[gabebear]

Developing a device around an ARM core is expensive and has high start-up costs. Remember that $1.8M is the average cost of a license, some people pay more, some less, but ARM holdings is a for-profit company, not a charity. They are out to make money.

Considering you have the likes of TI and Samsung mixed in the hundred or so licenses, the average price is going to be WAY higher than the smallest. If you are actually designing a custom modern CPU that you plan to make in a fab, you will be planning to make at least 100K pieces and paying salaries in the millions to your engineers. You also have to look at the alternatives; getting a current x86 license means you need to buy Via, Intel, or AMD since those companies are the only three that will likely ever have a license(i.e. billions for an x86 license).

Re:Openness?

[Matt_Bennett]

Going back to the original point I was trying to make- ARM is not "open" in any sense of the word. You don't get the core unless you have a lot to invest, and we are a long, long way from from someone using their makerbot to whip up a new processor. ARM has valuable IP- they don't hand their info to just anyone on the promise that "we're going to make lots of MONEY!" They want to see a return on their investment. If you're not going to make very many, you probably have to pay a higher licensing fee- and this is speculation here, but not going too far out on a limb, I'm guessing that the license+royalty fee still works out to something on the order of the (previously discussed) average.

As I haven't seen any, I'm pretty sure that any modern ARM core is complex and/or big enough to not fit in programmable logic- you've got to have at least an ASIC- being able to implement a core in programmable logic is vital for a true 'open source' core if we want to ever get out of the pure simulation phase. I'm not aware of any core that can run Linux out of programmable logic, though I would very much love to be shown one that does.

Going back to one of my previous posts- ARM isn't magic, and ARM and x86 aren't the only cores out there, let alone the only cores that can run Linux. Given a good kernel and a good compiler, the core doesn't matter.

I'm not even sure if AMD is really a 'licensee' of x86 since 1994 (intel canceled their agreement in 1986 and it was a legal battle until 1994)- as far as I am aware, AMD's current core is a 'clean room design' that owes no fees to Intel.

Re:Openness?

[gabebear]

Going back to the original point I was trying to make- ARM is not "open" in any sense of the word. You don't get the core unless you have a lot to invest, and we are a long, long way from from someone using their makerbot to whip up a new processor.

So something can't be "open" unless you can do it at home on the cheap? This argument is silly.

Going back to one of my previous posts- ARM isn't magic, and ARM and x86 aren't the only cores out there, let alone the only cores that can run Linux. Given a good kernel and a good compiler, the core doesn't matter.

HARDWARE DOES MATTER!!! I'll completely disagree with you here. ARM allows people to develop high-end systems on a chip that meet exact needs which is exactly why they are SOOO popular.

Re:Openness?

[Matt_Bennett]

Going back to the original point I was trying to make- ARM is not "open" in any sense of the word. You don't get the core unless you have a lot to invest, and we are a long, long way from from someone using their makerbot to whip up a new processor.

So something can't be "open" unless you can do it at home on the cheap? This argument is silly.

That is very much up to debate- but you'll find very few people who will call something with a $1.8M license fee open. No matter how you cut it, you are not going to be able to license the ARM core without giving something on the order of >$1M to ARM Holdings. And they won't give it to you on spec.Personally, if I'm charged anything more than a reasonable 'media fee' I don't consider it open. Would you call Windows "open" because it doesn't cost a lot to license? The concept of 'open' is very much tied the spirit of 'open source.' ARM is nowhere near open source. From the Wikipedia article on Open Source: "A main principle and practice of open-source software development is peer production by bartering and collaboration, with the end-product, source-material, "blueprints," and documentation available at no cost to the public. " We can quibble about what 'no cost' truly means, since we do pay for our computers and our connection to the internet. According to: http://en.wikipedia.org/wiki/Comparison_of_CPU_architectures, the ARM code is 'unknown' under "open" and "no" under royalty free.

Going back to one of my previous posts- ARM isn't magic, and ARM and x86 aren't the only cores out there, let alone the only cores that can run Linux. Given a good kernel and a good compiler, the core doesn't matter.

HARDWARE DOES MATTER!!! I'll completely disagree with you here. ARM allows people to develop high-end systems on a chip that meet exact needs which is exactly why they are SOOO popular.

Hell yes, hardware does matter, but nothing makes ARM magic. Yes, it is very popular, but not because of anything inherent in the design. It is popular because of a lower cost (but hugely significant) cost to license. Please point out something that makes ARM unique and more enabling than other cores. There is a core in every single microprocessor. Do you know the type of core in every device you own? I sure don't. ARM has a remarkably good branding strategy, but there is absolutely *NOTHING* in what you actually do with a modern microprocessor that forces you to a single (core) architecture.

Re:Openness?

[CheerfulMacFanboy]

Well, it is certainly more open than ARM, and that was the point I was making.

Secondly, as I said, there are many 486 clones. It is only around the introduction of Pentium Pro and MMX that the ISA began to be patented. Clones typically omit these instructions.

Patently false. 486 is open because its older than 20 years, and patents have run out. ARM is actually older, and anyone could implement older versions. Thus just as open.

Re:Openness?

[gabebear]

Going back to the original point I was trying to make- ARM is not "open" in any sense of the word. You don't get the core unless you have a lot to invest, and we are a long, long way from from someone using their makerbot to whip up a new processor.

So something can't be "open" unless you can do it at home on the cheap? This argument is silly.

...We can quibble about what 'no cost' truly means...

High performance CPUs are expensive to design and fab... deal with it. ARM is many thousands of times cheaper to license than anything comparable and thus "open". It looks like that "open" column in the Wikipedia table you pointed to means the company freely gives you a VHDL description of the base architecture(which is neat, but really only lets you simulate the chip in software very accurately). Applying open-source-software dogma here doesn't make sense.

there is absolutely *NOTHING* in what you actually do with a modern microprocessor that forces you to a single (core) architecture.

Is this in a hypothetical world where anything might exist or are you still talking about this world? Lots of stuff dictate what architecture you use, and they all pretty much boil down to cost: compiler/tools, foundries willing to fab your design, access to engineers, current design characteristics(power draw, int/float/vector performance, number of IO pins).

Re:Openness?

[Matt_Bennett]

I'm not sure where you get the "many thousands of times cheaper to license" - if that was so, companies like MIPS (which does have significant market presence) would be *HUGELY* more profitable.

I'm trying to make 2 points:

1) ARM is not open. It is licensable.

2) ARM is not magic. It does not enable you to do anything that you can't do on another core.

There are good compilers available for more than ARM- gcc has been ported to many different cores (ARM, SPARC, MIPS, x86 are just a few).

Foundries don't care about your core. They care about the individual transistors, I/O structures.

Power draw is a differentiator, but ARM, in terms of DMIPs/MHz, mA/MHz, or peak clock rate is not revolutionary- not the best, not the worst- the physics underlying the transistors is the same for everyone.

I/O pins are definitely not related to the core- The number and type is related to the implementation. ARM by itself, doesn't allow you direct access to the I/O pins.

Access to engineers is valuable- that is still about the license- an engineer costs a certain amount- that gets rolled into your license cost (or built into your per-core royalty) If you don't have a track record, your license is going to cost a lot more.

What I have seen is that ARM has a very good branding strategy, based upon the flawed perception of portability between different ARM cores (yes, the core ports, but that's a very small effort of the porting between manufacturers- the vast majority of your effort will be spent porting the peripherals, which are completely different manufacturer-manufacturer). It works out that the effort to port between the same ARM core from different manufacturers is about the same as porting from the ARM core part to a completely different core (they both end up requiring a lot of resources to complete).

Re:Openness?

[Anonymous Coward]

"ARM ... is open"
"As opposed to x86, which has a restricted licensing set"

Wow, that is one twisted view of reality.

Re:Openness?

[PipsqueakOnAP133]

Well written and much more diplomatic than what I would have said:

"Haha, suck it, Mr. We-don't-need-no-stable-kernel-ABI! Not so much fun being on the other end of the 'can't we program to a uniform standard' problem, is it, Linus?"

Re:Openness?

[JackDW]

486 clones were being produced in the 1990s while any patents were still valid, and not just by AMD. There were also Cyrix, IBM, VIA, ST, UMC...

Can you point me to any ARM clones? Any at all?

Re:Openness?

[CheerfulMacFanboy]

486 clones were being produced in the 1990s while any patents were still valid, and not just by AMD. There were also Cyrix, IBM, VIA, ST, UMC...

Can you point me to any ARM clones? Any at all?

Those 486 clones all had to be licensed. Intel stopped licensing when those clones became cheaper and faster than their own. If you think that is open, so be it.

As for ARM clones - what exactly do you mean? Aren't they all licensed clones? Or are you looking for things like Amulet? Google for it, if your open mind allows for it.

Re:Wait

[west]

I'm pretty certain he'd prefer a consortium that produces a common set of standards, but he raises an important point.

Choice costs.

It's wonderful that you have the a massively wide variety of choices, unconstrained by the a central authority, but don't forget that the cost of having that choice is going to be significant. There's a reason that almost all lines of business tend towards either a few big winners or, if the product is essentially identical, commoditization.

It's why I often wonder at why Linux users dream about taking over the desktop. If that did occur, it would mean a drive to lower cost that would result, almost inevitably, in the wholesale adoption of s single choice, reducing all the other choices to total irrelevance.

Missing the point

[Weaselmancer]

The reason why x86 is so unified is because they're all in PCs. You only have the one form factor to shoot at. So of course the CPUs will be highly similar.

ARM fills a different niche. You see ARM chips in tablets, phones, industrial control, routers...all over the place. Of course ARM chips will vary more wildly. They're trying to hit more targets. And those targets have unique and tightly defined parameters. That will put them at odds with other designs.

I mean hell, if the x86 has it all figured out so well, then why isn't your cellphone using one?

Re:Missing the point

[Anonymous Coward]

My cellphone is using one you insensitive clod!

Re:Missing the point

[gman003]

Uh, x86 is everywhere. PCs. Supercomputers. Microcontrollers. Embedded systems (you can still buy i386 chips because a lot of embedded systems like traffic light controllers use them). There's even been a few game consoles using it (original XBox and the Wonderswan series). Quite a few of them don't follow the PC standard, and that's fine. But there should still be a standard for common uses - even just covering smartphones, tablets and netbooks would be a major improvement over the current chaos.

Re:Missing the point

[agent_vee]

The reason phones use ARM chips is because ARM focused on providing low power consumption solutions. Intel/AMD basically ignored the mobile phone sector for a long time.

Re:Missing the point

[Svartalf]

ARM's everywhere. Look at most of your consumer electronics... Odds on, you're looking at an ARM in most of them. There's at least 1-2 ARMs in your X86 machines as well, doing tasks you wouldn't relegate to the X86.

Re:Missing the point

[Anonymous Coward]

Come back when you pass puberty and have real knowledge, pillock.

Re:Missing the point

[Weaselmancer]

Well yeah you can find x86 a few other places. I was working on a grocery store scale that was x86. But the thing was from an architecture point of view a PC in a funny box with a scale on top. Standard Linux distros worked on it unmodified. I tested that personally. The thing ran Ubuntu without a hitch.

And yeah you probably would expect to find 386 in traffic lights. Traffic lights are older than ARM chips, so you'd expect that.

But there should still be a standard for common uses - even just covering smartphones, tablets and netbooks would be a major improvement over the current chaos.

What standard would you propose? What standard could cover a CPU that you find in everything from routers to car dashboards? ARM is meant to be adaptable to corner cases. How would you fence that without hindering development?

Re:Missing the point

[gman003]

What standard would you propose? What standard could cover a CPU that you find in everything from routers to car dashboards? ARM is meant to be adaptable to corner cases. How would you fence that without hindering development?

Once again, you misunderstand me. I'm not suggesting we make a standard for any possible ARM device. I'm suggesting we make a set of standards for PC-like ARM computers - tablets, smartphones, netbooks, maybe even desktops and servers. That much is possible - x86 is able to work passably well in each, and it has a rather outdated standard not designed for those things. If you designed the standard to fit ARM's strengths (low power consumption, low cost), you could come up with something that works just as well as existing (mutually incompatible) standards, but which vastly speeds the process of designing and porting code.

Re:Missing the point

[Weaselmancer]

I'm not trying to misunderstand you - honest. I just don't see what your standard would fix. Code portability isn't really a huge problem on ARM. I do a lot of Windows CE work. And 99% of the code that runs on one platform will run on another. The base Microsoft binaries linked during a sysgen do not change from platform to platform, regardless of many design choices. Just select ARMV4I and you're good to go.

Sure, you could make a standard that says "This is what an ARM tablet is." Microsoft has already got one. If you want the Windows sticker on your new gadget there is a laundry list of things you have to meet. At least X number of touchscreen samples per second, X amount of hours before the battery drains when you're idle, etc. But if you don't follow these standards, CE will still run. You just won't get the fancy MS sticker when you ship.

Again, I'm just wondering what problem a standard would fix.

Re:Missing the point

[Anonymous Coward]

The different chips don't matter to code monkeys as the ABI is likely going to be the same, sharing the same ISA.
They do make developing and maintaining a kernel a lot harder. Sure, the hardware company will hire someone to write an initial port and give it away to Linux or MS, but you can't hope anyone, including themselves in a year, will fix it so it builds along the next kernel version.
While "screw the customer" seems to be the general motto these days, ultimately, people will move to vendors that don't require them to buy a new $1000 device just to be able to move Android up another point release.

ALSO SPRACH LINUX DUDE !!

[Anonymous Coward]

Yawn

More coding, less jabbering, linux dude !!

Diversity - Good/Bad?

[Anonymous Coward]

There's up-sides and down-sides. Diversity brings resilience in the face of software threats since you don't have homogeneous systems capable of executing the same malware payload code. The downside is exactly per article - support becomes much harder. I'd like to think if we had one CPU in the world then it would be rock-solid and extremely well tested because more eyes are looking at it. On the other hand it's a buisiness objective to "get it to 75% and ship it" so that one processor would probably just suck as much as any other hardware/software system out there but would cost 20x as much. You can't just say "open-source it" either because we all know how they love to fork everything to death. It's just the price of progress. Look on the bright side though, at least ASCII hasn't changed so our 7th grade poetry still loads even on these new-fangled iPads.

Quite agreeable

[symbolset]

So I wish I could agree. But ARM is following the same diversity explosion and darwinian selection as FOSS, and for the same reasons. Out of this chaos comes the wonderful bounty of choices in our modern digital buffet. PCs have become stagnant. If you want one they are still available, but don't really do anything more than they did 15 years ago.

Re:Quite agreeable

[houstonbofh]

Yet if you look at the FOSS projects with any real market penetration (outside the FOSS world) they are all the market leaders. Firefox, Apache, MySQL, Open Office, and so on. Yes, KOffice exists on Windows, but show me one non-linux type running it...

Right now ARM is a bunch of FOSS projects with no clear leader. Once there is one, it will get the mindshare, and hence the support. Then others will be compatible so they can use the ecosystem, and things will get better. But right now, it is Linux 1999.

Re:Quite agreeable

[symbolset]

In 1999 linux platforms for personal use weren't moving 650,000 units a day. They are now, taking nearly half of the global smartphone market share of sales. ARM is in the same boat, putting a PC in every pocket at the fore of the mobile revolution, bringing all-day tablets to the masses and driving the only growth in the IT industry at unheard-of rates. You point and stare, calling out "You're doing it wrong!" as the platform is taking over the world.

Don't you think that's silly? Surely there's some other platform that needs some helpful guidance more than ARM.

Re:Quite agreeable

[dave420]

Just think how well they'd be doing if they actually had some coherency of design. Just because they're doing awesomely (and I agree - they are) doesn't mean they're doing as well as they could be.

Re:Quite agreeable

[smallfries]

Sure, sure. Play the old cynic. The one under my desk is running particle simulations interactively using hundreds of GFlop/s. Looking back 15 years would have been the first 3dfx board and maybe a version of Quake. I think they are doing quite a few new things in that time. Improving vector processing performance by four orders of magnitude has resulted in new applications (for the PC, these things would have been available on mainframes previously) ...

No, no no no NO!

[AdrianKemp]

You know what we got with a single consistent architecture for PC CPUs? The need to use ARM chips.

For years there have been more promising options for instruction sets, and even the basic design of the chips. None of them were taken seriously because we were stuck with a standard.

Now, let's keep our standard, it's good for many things. But ARM is meant to solve some of the problems that it created, so why the hell would we want to give it the same problems?

Pot calling tea kettle black

[Anonymous Coward]

throwing it at a wall and seeing where it sticks, and making a chip out of what's stuck on the wall.

... is this different than how Linux and OSS in general have progressed?

more like Transmeta?

[Lead Butthead]

"ARM should be more like my previous employer Transmeta".

I hope by that he doesn't mean "unprofitable and get bought for pennies on the dollar" like Transmeta.

They can't do that

[SnarfQuest]

it looks like they're taking hardware and throwing it at a wall and seeing where it sticks, and making a chip out of what's stuck on the wall.

They can't do that! I have the patent!

Re:They can't do that

[Anonymous Coward]

They can't do that! I have the patent!

I think I have Prior Art in the form of AWA and the wiring wall. This was long before they started renting their name out to the Chinese badge engineers.

Let us not forget Transmeta...

[synthesizerpatel]

One of the reasons ARM has succeeded over Intel in the embedded platform is exactly because it's a hodgepodge in terms of implementation.. Arm just designs the chip, they don't make it, they leave that up to others, who then in turn support their own chips by providing kernel patches - which has been amazingly successful for Linux (and incidentally the non-linuxy iPhone as well)

Not to talk trash, he definitely understands the kernel and software but the nuances of hardware development and what makes hardware successful or unsuccessful aren't in his core skill set. After all, way back when he could have picked any position anywhere he picked Transmeta.

A lot has changed since then but ARM has done nothing but help Linux. If your chip vendor has a poopy Linux implementation they'll sell less. If they have a great one (and great documentation) they'll sell more. TI's a pretty good example of an awesome ARM / Linux implementation, and.. there are less awesome examples..

Re:Let us not forget Transmeta...

[Jonner]

A lot has changed since then but ARM has done nothing but help Linux. If your chip vendor has a poopy Linux implementation they'll sell less. If they have a great one (and great documentation) they'll sell more. TI's a pretty good example of an awesome ARM / Linux implementation, and.. there are less awesome examples..

How do you define "help Linux"? The popularity of Linux on ARM has produced a giant, acrimonious fork which is not helpful to the community in general. Obviously, this wouldn't have happened in the first place if Linux and ARM weren't good for each other, but for the community to function well, things need to change. Linus is hopeful that this will be resolved in four or five years as a result of his and others' efforts to fix the very problems he's complaining about. The problem is not so much "poopy" Linux forks on ARM devices as it is the fact that there are many good forks that don't fit together very well.

Re:Let us not forget Transmeta...

[Anonymous Coward]

+1 for use of "poopy"

Microsoft to the rescue

[Anonymous Coward]

What this needs is for Microsoft to work with an ARM SoC vendor to come up with a platform architecture for an ARM-based server running Windows. It's in Microsoft's best interests (being that Windows is a pay-for OS) to take the lead here and I expect they would do a damn fine job.

With an architecture in place and a single vendor building to that specification, other ARM SoC manufacturers who want to play at the Windows table will have to conform. This would be the start of a common ARM platform. It may not be perfect, but it would be common.

Hate on MS all you like, but they could own the shit out of this.

Features of desktop vs mobile ARM

[Twinbee]

Can someone give me an example of the kind of non-compatible functionality you'd get with a desktop ARM versus a mobile version.

It seems in my eyes they should implement all the features for great cross compatibility, but just make them slower if need be. I doubt it would up much more die space...

I really dislike fragmented environments, and at most, we should have 2 ARM versions, preferably one, and not for example 20000.

Re:Features of desktop vs mobile ARM

[Matt_Bennett]

It's not desktop vs. mobile, it is manufacturer X vs. manufacturer Y. ARM is just the core- the company doesn't make chips. They license their core to people who design with it. What is fragmented is everything outside the core- that is, the value that each licensee adds to the core to make their own product. They're embedded processors- they get surrounded by many peripherals such as analog to digital converters, interrupt controllers, serial ports, memory interfaces ... the list goes on and on.

To me, it brings back memories of the early PC era, where you may have had a game with *awesome* graphics and sound, but you had to spend hours fiddling with the IRQs and other settings to get the program to work reliably.

Re:Features of desktop vs mobile ARM

[Twinbee]

Thanks that helps clear things up.

But apart from maybe "memory interfaces" maybe, the other things you mentioned (like analog to digital converters) wouldn't be of concern to the average programmer who would still maintain cross-compatibility across devices, assuming he didn't write for special things like cameras, sounds recorders or networking etc.

Re:Features of desktop vs mobile ARM

[Megane]

The problem is that even something as simple as a UART serial port is completely different from SoC manufacturer to manufacturer. In the PC world, only the 8250 and its derived chips were used. Even the Zilog SCC (which was the standard in the MacOS world until USB made it obsolete) was completely alien to standard PCs. Not only that, but the PC had a crazy keyboard interface that became an instant standard, even to the point that the original XBox had an A20 gate in its chipset.

So to even get console output from your kernel, it has to be built with the right UART drivers for your specific CPU. And there is no standard for auto-detecting hardware, either. I don't think there's any vendor-agnostic way to determine what ARM and SoC version you are using.

Re:Features of desktop vs mobile ARM

[Matt_Bennett]

All the core does (by itself) is math/logic functions, conditionals, and move data around. *EVERYTHING* else is done by a peripheral. Embedded processors are (almost by definition) packed with peripherals. We get very used to these peripherals, but they're there, and if you want your computer to do anything other than serve as a way to deplete batteries, you've got to send data to/from a peripheral. Every different ARM variant has a different set of peripherals and different ways to use them- hence the fragmentation in the Linux kernel. There really isn't anything magic about ARM- the differentiation is mostly marketing.

Re:Features of desktop vs mobile ARM

[Anonymous Coward]

But apart from maybe "memory interfaces" maybe, the other things you mentioned (like analog to digital converters) wouldn't be of concern to the average programmer who would still maintain cross-compatibility across devices, assuming he didn't write for special things like cameras, sounds recorders or networking etc.

And that is why it is the operating system writers that complain about it. They are the ones who tries to glue things together so that the application programmer gets a specified interface regardless of underlying hardware.

Re:Features of desktop vs mobile ARM

[Anonymous Coward]

NO, the only reason you should go Embedded, is because the peripherals are embedded... Average ARM programmer concerns peripherals, or may not, but that code should be equally compatible with x86 devices.

In ARM world peripherals (like ADC) ARE memory interfaces...
So in vendor A) address 0x00FF is the ADC, and in vendor B) address 0x00FF configures the RAM access...

Abstraction layer and drivers solve this issue, but kernel developers are the ones that make and optimise the abstraction layer, and they need a standard, to unify efforts and prevent duplicated work.

Re:Features of desktop vs mobile ARM

[oursland]

Sure, but for this you'll have to pardon me as we dig deep. Let's look at the arm branch within the kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See each of those mach-* and plat-* directories? Each of those are major architectural variants which use the ARM Instruction Set Architecture for their CPU.

For comparison, here's the X86 arch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/x86;h=b12a856aa5e889280247287d48241beb16eb423c;hb=HEAD

But, to see where the problem really lies let's dig deeper. Let's select a popular architecture, the Texas Instruments OMAP2, also shared by the OMAP3 and OMAP4 series.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm;h=d247ffd8707069e63d0b065f5be9ce460e062536;hb=HEAD

See all of those board-* files? Each of those represents a specific implementation of the OMAP2+ architecture. The rest of the files are support for the underlying functionality exposed by these board files.

You see, this is a mess. The current state is akin to having each variant of X86 with its own file. E.g. an architecture directory for each PC manufacturer (IBM, Dell, HP, Compaq, Lenovo, etc) and then in each directory the variant implementation files (Lenovo X40, X41, T40, T60, T60p; Compaq Presario CQ50, CQ56, CQ62 and so on). Whenever you change an underlying subsystem used by many boards, such as USB or Flash, you have to visit each of these architectures and boards and update them.

The reason for the mess in ARM is that ARM is the CPU core, an ISA, that's all. Beyond that it is completely nonstandard. Memory locations, flash interfaces, Serial Peripheral Interface (SPI), Two-Wire Interfaces (I2C), USB controllers and numerous other hardware configurations are all chip specific. The PC has standardized these using the BIOS, EFI, PCI and other industry wide standards. Sure you'll need drivers to use the devices, but at least you can boot up and detect them. From there it is simply a matter of loading the module and away you go.

The lack of standards in ARM necessitates these board files. One system may boot using one board file, but the next may not be able to get their RAM configured appropriately using the same board file.

And with regards to a consistent ISA, that's not even true. There are multiple implementations of some functionality such as floating point. ARM has a couple implementations (notably Vector Floating Point (VFP) and NEON), but some manufacturers have decided to create their own implementations such as Cirrus' Maverick Crunch. But this isn't even a real concern here, as that is more a matter for the compiler.

Re:Features of desktop vs mobile ARM

[Anonymous Coward]

It does actually become a point of concern for them as well; as the Operating System (Kernel) cannot be guaranteed to be uniform across platforms. This forces them to write much more complex code to handle a wider variety of kernel versions than they ideally should have to. See the current Android fragmentation; its caused in large by this very issue.

Re:Wait

[houstonbofh]

It's why I often wonder at why Linux users dream about taking over the desktop. If that did occur, it would mean a drive to lower cost that would result, almost inevitably, in the wholesale adoption of s single choice, reducing all the other choices to total irrelevance.

But when that choice goes goofy, you can change it quickly. Like the watershead from KDE for a while. Next it will be from Unity and Gnome Shell, for a while. Then the leaders either shape up, or fall aside, like XFree86. http://en.wikipedia.org/wiki/XFree86 You can have a market leader (A good thing for standards) and still have choice. (A good thing for freedom)

Re:Wait

[obarthelemy]

That's "Do as I say, not as I do" at its finest. Meanwhile, on the Linux front, choice is great, if you're not happy roll your own, and uniformization is death.

Re:Wait

[symbolset]

ARM chips sell over 10x IA chip volumes. More volume supports more choices. Linux runs on a good fraction and I'm writing this on one. It appears that the cost to migrate to a new chip is so low that a gang of volunteers can keep up with hundreds of phone and tablet models and deliver rapid platform updates quite swiftly. I don't see a problem.

This is the "beware fragmentation" pitch we laughed at in distros, in Linux apps, in Android phones and tablets. This is absurd and deserves ridicule. Fragmentation is choice. Do we need to cringe in peril when we discover that our corner convenience store's water market is so fragmented that it offers 17 choices in simple, unflavored uncolored water? No. We should ask why the water often costs more than Gasoline, but that is a separate issue.

what he means is -

[Anonymous Coward]

Translation: "I'm irked that Apple has the best ARM silicon, followed closely by the Tegra and the Snapdragon, and all the other players are mostly just experiments which will fade away, which means the majority of the ARM market is not reachable with the Linux kernel."

Suggestion: If your interest is mass market appeal, then just focus on the 2 or 3 best pieces of silicon, and forget about the rest. Optimize the kernel for performance on those.

In other markets, ARM chips are widely differentiated for a reason, they target countless embedded systems, something the "PC" has never been good at. Either do the work to support all the different flavors, or stop worrying about it. I think ARM is successful specifically because it's the anti-Intel platform.

Re:what he means is -

[Anonymous Coward]

Translation: "I'm irked that Apple has the best ARM silicon, followed closely by the Tegra and the Snapdragon, and all the other players are mostly just experiments which will fade away, which means the majority of the ARM market is not reachable with the Linux kernel."

That's a completely stupid 'translation'. Torvalds' complaints about ARM aren't new; I remember reading an earlier edition of this rant long before the rise of either iOS or Android. They have nothing to do with envy of any one ARM implementation, and everything to do with kernel maintenance headaches.

The problem Linus has is that in the PC world, there are standards for all levels of the system, not just the CPU instruction set. They might not be good or efficient standards, but they exist and they're useful if you're writing software. For example, you can count on virtually every peripheral being (or appearing to be) a PCI device. This is very nice if you're trying to write software which scans for devices and matches them to drivers; PCI has a regularized model for doing this kind of thing. But even more so than that, PCs have standardized software interfaces (BIOS/EFI) which let them handle lots of messy stuff in pre-kernel boot code which hands an already-initialized PC off to Linux, complete with data tables pointing Linux at devices found by the firmware. This greatly reduces the amount of machine-specific cruft which has to live inside Linux kernel code.

On the ARM side of things, there are no standards for any of that. It's the wild west. Any conceivable way to make hardware visible to software can be and has been tried, and since all of them are different, it's very hard to even do so much as fit them all into a sane common support framework in the Linux kernel. Many of the companies developing SoCs don't even have a BIOS equivalent, they just try to do all the hardware init in-kernel. The result is an extremely messy ARM architecture subtree in Linux, one which has to account for probably hundreds of different SoCs, each with its own unique take on things related to peripherals and booting.

I'm not sure Linus' take on things is ever going to get results, simply because it's in the nature of SoCs to be customized that way.

Re:Wait

[west]

I'm not so certain. If the business community settles in on a standard, instead of the Linux community being composed of a dozen different distributions, all of which have roughly equal mindshare among contributors, you end up with only one to which you contribute if you want to be at all relevant, which means the alternatives wither from lack of customer and eventually programmer interest.

My thesis (speculation to be sure, but built on observation), is that you *cannot* sustain that level of choice in a market that is in any way mature.

sounds very similar, but what are the solutions?

[lkcl]

linus's views sound very similar to what i've written about, at some length on this subject: https://lkml.org/lkml/2011/7/1/473

the thing is that absolutely nobody has come up with any solutions. the only solution i've heard is the one that i recommended, and there's been no reaction or response to it, as of yet.

the problem is the sheer overwhelming diversity. therefore, the solution is to prioritise linux kernel patches that come from hardware syndicates or specifications that cover more than just the one hardware device. for example, a patch to add in ARM USB3 support would instantly be accepted, because it covers multiple hardware devices. for example, a reference board would be instantly accepted, because it allows companies plural to develop platforms based around it.

what people are forgetting is that because there is no BIOS in the ARM world and no "common hardware platform" (PCI, PCIe, Northbridge, Southbridge - in most cases all of those things are gone. ARM CPUs with PCIe are exceptionally rare). and often there are massive differences between CPUs even on a minor upgrade from the same manufacturer, each hardware device has to have a custom-tailored device layout, and that means a custom-tailored linux kernel.

That would be great.

[symbolset]

That should sell in the dozens.

Re:Wait

[sjames]

More like wouldn't it be nice if they would at least occasionally meet, talk shop, and perhaps agree voluntarily to be a bit more compatible. That and don't go making changes for the sake of changes. Pick a design that works and stick with it.

arm vs x86

[yupa]

First arm only does the cpu, everything that it is around it (timer, interrupt controller, memory controller, uart ,...) can be anything.

And there is no easy way to discover them (like pci bus, acpi, ...). That what device tree want to do.
But that won't really solve the code size. Embedded company want to reduce cost and often design simple soc block (gpio, uart, ...), and this make the number of driver very big.
Also there no standard interface like ehci, ahci, ...
Even the same vendor can change the controller across the chip generation.

So I think it will be very difficult to unify things. What the advantage of arm for soc maker. There are free to do what they want.

Re:arm vs x86

[kent.dickey]

Code size doesn't really apply--this is a discussion about Linux. If you're running Linux, you're not counting KBs. Maybe you're counting MBs. You may only be counting GBs (the smallest iPhone was 8GB). And ARM does provide a timer, interrupt controller, and memory controller. Not all customers use them, and only the interrupt controller has a generic "architecture" which could be said to apply to any interrupt controller. It's ironic, though, since I think everyone uses the ARM interrupt controller in any case.

It's basically ARM's fault. ARM has a predilection for leaving specs more vague than they should, and then making minor improvements that aren't backwards compatible at the OS level with each new CPU generation. User-level code tends to be backwards-compatible at least. As an example, they changed the page table format between ARMv6 (ARM11xx series) and ARMv7 (Cortex series). ARM's move to multiprocessors is new and its not clear the current OS-level view will change in the future. ARM also only documents the CPU and the IP they provide (interconnect, a memory controller, an L2 cache controller, and an interrupt controller). There is no larger system architecture, like x86 has, not even a de facto one. The x86 architecture is basically PCI based--generally, all devices appear in PCI space, with a BIOS interface for OS'es to use to discover memory layouts. The x86 world was crazy before Pentium and PCI came along, and then very stable since then.

Part of it is Linux's fault. If Linus had a distaste for #ifdefs, and instead required patches use if()/else, then vendors would be forced to adopt a more common architecture. As it is now, the vendors push their incompatibilities into huge patches in Linux, at no real code size or speed cost when run, but complicating Linux with very complex #ifdef mazes. Basically, Linux pays the cost of everyone doing something different.

So, if your CPU vendor requires pretty deep OS changes for each CPU, there's no incentive for licensees to create a system architecture so that the old OS runs on new hardware. If ARM were to accept running old OSes on new hardware as a requirement, they would have to create a system architecture. Just having a standardized memory layout would be a nice start. Having hardware be more self-descriptive could be done very simply and cheaply. PCI is probably not the best choice, but having hardware have the equivalent of Vendor/Device ID that was globally unique, and a way to find peripherals would be a start. It's just that ARM doesn't care, and probably won't care until its customers demand it to care.

Re:arm vs x86

[expatriot]

Thus far ARM has not focused on system specifications other than basic binary code interface. The Linaro group http://www.linaro.org/about-linaro/ has now started developing a more system level approach and a concerted effort to get more consistency with upstream engineering. The situation has been a bit confused until now, but it will get a lot better with the Cortex-A9 and A15 systems for Android, Linux, and Microsoft.

Re:Wait

[nschubach]

It's why I often wonder at why Linux users dream about taking over the desktop. If that did occur, it would mean a drive to lower cost that would result, almost inevitably, in the wholesale adoption of s single choice, reducing all the other choices to total irrelevance.

I don't understand this logic.if the hardware was standardized, anyone could make the chip and someone would find a way to compete (speed improvements, power consumption, ...)

The whole deal with ARM standards is probably going to be solved with Windows 8 (unfortunately) if it sticks to the promise of running on ARM. Microsoft will step in and say "Here is what we will support" and the chip shops will fall in step.

Re:Wait

[west]

I don't understand this logic.if the hardware was standardized, anyone could make the chip and someone would find a way to compete (speed improvements, power consumption, ...)

My comment about the desktop was unrelated to ARM. I was trying to point out that if you become a significant player in a market where cost rather than flexibility is the main factor (i.e. the mainstream desktop), you are likely to *lose* a lot of your current choice.

Your point about Windows 8 is a very good one. We may lose a lot of choice because of it. On the other hand, much reduced costs to enter a now much larger market may well boost participation significantly.

Since we have a WOOSHER...

[Osgeld]

let me expand this, saying I have linux on an arm cpu is similar to saying I have a 6052 running basic. In reality it means nothing because each arm setup is totally different outside of its core. just like every computer from the 80's had a specialized basic custom tailored setup

Re:Wait

[jonbryce]

Microsoft already has two operating systems that run on ARM, Windows CE (aka Windows Mobile) and Windows Phone; so I'm not so sure about that. Besides iOS and Android are the market leaders in the ARM space, that probably isn't likely to change any time soon, and Windows 8 probably won't run on any of those devices.

the problem is the many programmers, all alone

[Chirs]

ARM is a bunch of different companies all contributing code to make their own device work. The problem is that very little effort is being spent to extract all the common bits, so you end up with many slightly different implementations of the same thing.

Re:Wait

[Tenebrousedge]

So far we have POSIX, Linux Standard Base, and the Free Desktop "standards". Standards are always optional, whatever the "business community" says. There are many categories of software, but there aren't terribly many different competing projects per category. As concerns distros, there are the debian-based distros, the fedora/RHEL based distros: everyone else is more or less "niche", and generally not intended for mainstream consumption.

"Relevant" in the FOSS world means your code compiles on new systems and your application does what it says on the tin. TeX and wget are highly relevant but hardly developed at all these days. Your definition of relevancy seems to be a bit more subjective, and betrays a woeful depth of ignorance of the software world.

Where is the news

[Latinhypercube]

I fail to see where the news is here...
the PC rules !!! Long live the PC !!! Stick your ipad up your arse. It's just a big iphone.

x86 is everywhere?

[Joseph_Daniel_Zukige]

No, not really everywhere. Not nearly as everywhere as 68K (still). No where nearly as everywhere as ARM.

x86 is not really appropriate to embedded and real time. If the other processors which are tend to get tuned, well, x86 in embedded is going to tend to get even more special hardware.

Not the same x86, however, and that's really the problem we're trying to talk about here. (And failing.)

It has to fork.

[Joseph_Daniel_Zukige]

We need a whole bunch of co-existent forks.

And some way to manage them all.

That's the whole point here, I think.

An example - i.mx53 Freescale ARM Cortex A8

[Anonymous Coward]

Time to call out an ARM manufacturer.

We recently got a Freescale i.mx53 Quickstart Board. Nice piece of kit they just released. Seems good for many of the applications we're thinking of.

Problem: It ships with 2.6.35, more than a year old. With 505 patches. And proprietary graphics.

We really want the 3.0 kernel, because it's supported by the -rt patches.

Freescale, Freescale, Freescale! PLEASE make more of an effort to mainline your changes! And use a graphics core that has drivers that can be recompiled, even if it's the NVIDIA model.

Standard platforms are okay, ...

[Joseph_Daniel_Zukige]

Standard platforms are okay, but eventually we need to start working on tools to deal with the complexity.

Re:Standard platforms are okay, ...

[oursland]

but eventually we need to start working on tools to deal with the complexity.

Like standards?

Work on that started in the 1960's

[symbolset]

Linux is written primarily in C. The reason for this is that C was designed from the very beginning to be ported to new technologies.

You are a really funny guy, Linus!

[aglider]

ARM is this hodgepodge of five or six major companies and tens of minor companies making random pieces of hardware, and it looks like they're taking hardware and throwing it at a wall and seeing where it sticks, and making a chip out of what's stuck on the wall.

I'm not sure whether this vision is more hilarious than deep or vice versa. Maybe both.

Sue Scott

[Anonymous Coward]

www.bestgpsx.com.best gps http://www.bestgpsx.com