Linux on ARM breakthrough to take away Torvalds' arse pain A single Linux kernel build that can run on various ARM-powered kit from competing manufacturers has come closer to reality, much to Linus Torvalds' relief. Unlike the world of x86 PCs, which has standardised and well-documented hardware, there is little consistency across ARM-compatible systems beyond the basic processor …
We can only hope. Personally I was looking forward to the idea of an ARM desktop chip, or perhaps an ARM games console (thanksOUYA) and this kinda makes it more likely to happen.
I mean OUYA is my prime example here. Sure it may be the first, but considering it's built on a slightly customised android, if linux can come out on multiple ARM setups, who's to say that this may not be the new "games console" standard. OUYA first, a few years, then open it up as a 'standard' a few years down the line Sony or Google could release their own 'OUYA standard console" with their own updated hardware etc. It could still play all the old games, and all the new ones.
I know it'll never happen, but one can dream right?
(I actually plan on buying a couple OUYA to add to my still non existant RaspPi cluster. Been wating over 3 months for that sucker to get shipped)
I mean lets face it, games consoles there days the main thing they're focusing on improving is bandwidth / latency issues. ARM is proven to be a great platform for SOC (better than intel and amd attempts) so get a pair of decently powered quad core ARM chips, stick a pair of graphics chips on there for an SLi type setup, decent memory, that'd be the lowest possible latency, highest possible bandwidth, low power consumption, minimal form factor, and compared to shit like the CellBBE probably winds up cheaper.
Here's the thing.
Imagine an ARM chip is a brick. When you build a house you want all your bricks the same, but supplier A has bricks of one size, supplier B does them in another, and supplier C has seven bricks all of varying sizes, but none the same as A and B. that is the problem with ARM fragmentation
Android is a clothing store, it is in a building built of bricks, but you don't want every clothing store to be the same, apparently fashion wants them similar, but not identical, different branding, aimed at girls or boys or different age groups, this is Android.
The Linux problem is more like a licensing issue. You can only build your store in a house built with bricks from supplier A, you cannot then move that same shop to a building built with supplier Bs bricks because of some legal issue.
Bad analogies are fun.
Obviously if you are able to licence a CPU core and build a system on chip to meet your own requirements then it isn't going to be the same as another.
This is all about producing an optimal design with only the components you need, so you aren't powering up circuits that are doing nothing. Important when you're producing a battery powered device.
If someone wants to propose a "ARM Desktop" standard then they should do so.
Choice is good! People scratching their own itch is good! Innovation is good!
So is the creator of the most fragmented and least used OS on the planet now saying that choice is bad? There is a reason the Linux adoption is sub-1% and falling. Fragmentation of skills, incompatibility and all the other grief that comes from too much choice.
Give it up Linus - the experiment is dead and you have failed.
Give it up Linus - the experiment is dead and you have failed.
Wow...you're fucking clueless, mate.
Ignoring the desktop market share that's actually closer to 2%, and ignoring the plethora of other devices that run it (WTF do you think Android is?), some estimates put Linux at 60% of the server market. Sixty. A majority. Some failure, eh?
Posted from Linux, via a network controlled by Linux, to a website running on Linux.
"There is a reason the Linux adoption is sub-1% and falling. Fragmentation of skills, incompatibility and all the other grief that comes from too much choice."
It's nice to see your knowledge of programming in a Unix environment is on a par with your knowledge of OS market shares.
"Give it up Linus - the experiment is dead and you have failed."
Interesting - you truly don't have a clue, do you ?
Sorry mate, you've failed a basic comprehension test. You're not just wrong, but also off topic.
Linux is the *most* widely used operating system on the planet. Just not on the desktop-- in fact there's a good chance you own more devices running Linux than any other operating system (your router, your set top box, your distributed music system, your TV, your home security system, your car's infotainment system, your smart washing machine, the smart meter for your home, your GPS system, ... etc. I'm assuming you don't own an Android phone BTW).
For the topic being discussed (ARM based embedded/small device systems such as I listed above) there are a myriad of custom dedicated lightweight OSes, and Linux. The reason why Linux is used is because you can get in and muck around with the Kernel in order to customise and optimise it for the hardware that you are trying to build. Good luck to any hardware manufacturer trying to do that with whatever OS you are a proponent of.
yup last time I checked computers in my household these were:
* ADSL router with firewall (Linux)
* WiFi access point (not sure, likely Linux)
* media player box (Linux)
* phones (erm, not Linux - these are RIM)
* tablet (RIM again, more precisely QNX)
* camcorder (no idea)
* DSLR (no idea)
* mobile wifi (no idea, likely Linux)
* bluray player (no idea)
.
.
.
* one desktop computer running Windows 7
In the eyes of an ignorant, I seem to be running Windows on one and the only computer I own!
Hardware makers use Arm as a basis for what they want.
Why should they create a complex, bloated processor set so you can keep your code small? Do you know how much that would ramp up pricing for the most basic hardware?
A set top box does not need the same hardware as a multi-processor supercomputer or a Sat Nav device or a Mobile phone and on and on....
Jeez maybe his mum should of said No a little more often when he was a kid.
Why should they create a complex, bloated processor set so you can keep your code small? Do you know how much that would ramp up pricing for the most basic hardware?
Ignoring most of the problems with this interpretation, I'll pick apart your small code.
Look at it this way. Smaller codebases have their own advantages, suppose, for example, potentially easier debugging/troubleshooting due to less code to be read-period, nevermind presumably cleaner code; leading to potentially less man-hours spent on debugging and compiling; saving money on man-hours to offset any potential added-costs.
I'm sure I'm skipping or missing a lot here. In addition to everything I skipped right past.
Other folk are free to rip this all to shreds or accuse me of feeding the troll.
A set top box does not need the same hardware as a multi-processor supercomputer or a Sat Nav device or a Mobile phone and on and on....
I think you've missed the forest for a couple of trees here.
But I feel wordy enough for tonight.
He's not complaining they aren't making complex processors. He's complaining that there are four companies that are putting little red 2mm x 2mm x2mm boxes on their board that are supplied from commodity red 2mm x 2mm x 2mm vendors and that the logical interface to the box is the same. But company A calls it a hoser, company b calls it a lifter, company D calls it a vator, and company calls it a faucet, and each of them customize a front end that only interacts with that box and Linux has to work with the front end instead of the box, or even better, a cross industry standard that would let you talk to the box regardless of which ARM chip is used.
Why not?
In fact, could that not start with something inspired by (say) the Windows 8 on ARM standard, which presumably already supports a variety of compatible but not necessarily identical platforms, and remove the MS lockins such as cryptographically secure boot.
That's a good part of the job already done, then add additional bits as required?
Anyway, I don't know Linus, but I have had the pleasure of working with Dave Rusling. Thanks Dave.
I'd wager there is nothing innately compatible between the Win8 RT supported ARM chipsets and that most likely they exhibit the same issues Linus is complaining about here. I could be wrong of course.
Microsoft is also only supporting, I believe, 3 ARM chips... putting it within the realm of possibility IMHO that they are managing a unique variant of the kernal/OS for each.
That said, Win8 RT is getting more ARM hardware in new(ish) form factors out in the market. The chips being used are, I believe, already supported by Linux. I'd be curious if any of the mfrs release non Win8 RT versions of their hardware - without the non-removable boot lock - to be used with other OSs. That really would be something.
Microsoft had the power to, and did, bash the SoC vendors' heads together and make them produce standard hardware, at least standard enough that the same Windows code can boot and run on all systems.
ARM systems for Windows RT (and Windows Phone 8) must support UEFI boot, and must support ACPI to describe the hardware in the system. They use a new 'Hardware-reduced' profile of ACPI 5.0 that doesn't include any of the legacy x86 interrupt handling and device routing, or PCI bus; they can use General Purpose I/O pins which are the more common way of interfacing to the SoC. The only other requirement is that the device implements the 'Multiprocessor Startup for ARM Platforms' specification, so that the OS can correctly control multi-core CPUs. (See http://www.acpica.org/download/MP%20Startup%20for%20ARM%20platforms.doc.)
Microsoft have also created new categories of Class Driver, for example extending the USB Human Interface Device specification for sensors (accelerometer, GPS, compass, biometrics, etc) via the USB Implementers' Forum. Class drivers are used with generic hardware to avoid the OEM having to write drivers (which, if they keep up to date at all, they tend to do badly.)
These requirements are why (in my estimation) Windows Phone 7 hardware cannot run Windows Phone 8 and won't be upgradable. The sensors probably aren't connected via USB, the boot loader isn't UEFI, it won't implement ACPI. The MP startup protocol is really about communication between the firmware layer and the OS, so assuming you're replacing the base firmware anyway.
Microsoft have done this deliberately to ensure that they can update the operating system through Windows Update, in exactly the same way that they do now for x86, x64 and (where supported) Itanium. No custom builds per manufacturer - while the NT Hardware Abstraction Layer technically still exists, on x86/x64 all systems must now use the multiprocessor, ACPI, APIC HAL. That applies to Windows Phone 8 as well, I believe. They are, I believe, concerned that the Windows Phone OEMs fail to deliver updates, particularly with the carriers having to approve many different updates, and see it as a key differentiator against Android.
The author clearly has no clue about the different flavors of x86, and I'm not talking 64bit here. Just look at linux distros and most if not all already offer 2 kernels, a (very) basic 486 one and a full-option 686 one. And then there's pae,...
Only recently did I come across a dual-core system that was only using 1 core because of an incorrect x86 linux kernel. Yes it ran, but that' s not the point....
"Yes it ran, but that' s not the point...."
Ah, this is where your argument falls down. The ARM world is so fragmented that SoC designers will stick their hardware registers and other chipset features, let alone the RAM and ROM start addresses, wherever they like (more or less). So a kernel built for one board won't boot at all on another.
However, x86 land is so backwards compatible that your basic chipset will always appear where you expect it. Yes, there are differences - such as SMP - but that's purely because new features have turned up over time. It's no where near as wild as the ARM arena.
C.
Diodesign seems to be confusing x86 chippery with the impact of the Wintel (Intel/Microsoft) PC9x specs [1] (and whatever the replacement of PC9x was/is).
You can in principle have x86 systems that aren't PC9x compatible. In practice they don't exist in significant volume because the only reason to use x86 is to be Windows compatible.
If you don't need to be Windows compatible, you can choose the chip that fits best. Mostly, vendors choose something ARM based. Introducing a common hardware spec for ARM won't increase ARM market penetration much, but a common hardware spec will reduce the effort needed to properly support any given SoC implementation, which is worthwhile in itself.
[1] http://en.wikipedia.org/wiki/PC_System_Design_Guide
"Ah, this is where your argument falls down." - the basic boot of a PC is fairly standardised, as are the locations of generic hardware elements (serial, parallel, assuming you can find a computer with them, that is).
However... once you get beyond the real basic stuff, you will find it isn't so compatible. The driving factor is "will it run Windows?", and so long as the company is willing to supply a driver (or get one built into the OS), then yes it will run Windows. But look at the hardware. There's a driver for the USB chipset, there's a driver for the WiFi thingy, there's a driver for the graphics card. Now this in itself is no surprise, but if you stick my computer next to my mothers and examine the machine, you will find all the same drivers only different. It has a built-in USB hub. Not the same. It has a WiFi card. But a different one. It has a graphics card from a different company with different setup/configuration and different capabilities beyond the normal "here's a picture to look at".
You might remember some of this if you think back to the early days of Red Hat Linux and the long lists of what it did and did not work with. The situation then was better than ARM today because a Y2K era PC will at least boot in basic x86 mode with a CGA-text style display. Much beyond that was... let's just say it wasn't unknown to have startx freeze, crash, or return to the command line having apparently done nothing. You'd need arcane incantations to get the windowing system talking to the graphics card, and you'd need to sacrifice small cute things if you didn't want it stuck in 16 colour VGA ugliness.
Sure, ARM SoCs have taken great liberties with their boot-up procedures, and maybe Linux will be the platform that starts to bring coherence to the SoCs so that a basic bit of code will stand a chance of starting even even if it can't do the exciting stuff? Though, don't many ARM boards start off with U-Boot or similar? Isn't that capable of bringing up the basic initialisation so some sort of kernel can start (even if "finding the video display device" is more problematic)?
I see ARM SoCs to be about on par with the home computer boom of the mid-'80s. There are many types, mostly incompatible with each other. One or two will eventually win out, the rest will be destined to become relics. We just need to go though the motions as protectionism is still the order of the day (as witnessed by the so-called datasheet for the RaspberryPi's SoC which does not even describe the dumb-framebuffer video mode, making it pretty useless for attempting to develop/port anything; compare with the Beagle OMAP3 datasheet's incredible amount of detail); and the big players somehow don't seem to see history repeating itself again. I would point out that the x86 PC design was kind of icky, so if it wasn't for DOS and then Windows, it is possible the PC itself would have been a relic and we'd be using 2GHz 68000-derived machines...running Windows or Ubuntu (among others).
tl;dr: You're comparing a new growth area (SoCs) with fairly custom requirements (primarily, most bang for least power, and extremely small size) against a computer system of around a quarter century of maturity, a large portion of that time spent with the single question "does it run Windows?". I do not believe the PC is standardised because it is the right thing to do, I believe the PC is standardised because a setup that failed when you inserted that Windows CD would be a system destined to crash and burn and leave a nasty stain on history.
you'd need to sacrifice small cute things if you didn't want it stuck in 16 colour VGA ugliness.
VGA/SVGA mdoes are pretty standard and 256 color (some "VESA" are hi-color ->32/64k ones but you may not get feedback if there is anything on the screen).
I am used to 'color' spelling as in all languages it's just the american one: 'color'.
There seems to be a lot of confusion in this thread. It's really nothing to do with the CPU architecture, but the platform e.g. address and function of hardware registers for peripheral devices, I/O, etc. which vary between SoCs. These are not specified by ARM who only supply the CPU/ISA. But the PC platform has most of these pretty much standardised (first by IBM and copied by the clones, then later by Intel), or at least specifies a way for the OS to automatically discover them. You could have the exact same problem with x86 if you created a new incompatible platform using that processor.
It's a bit like the horror situation with video capture cards.
Have a look at the mess that is the kernel module for bt8*8 cards.
A multitude of tuners. A fairly small number of actual decoder chips but configured in a plethora of different GPIO combinations. Some cards announcing themselves via the PCI information as the same thing but actually quite different in terms of their real configuration. A total mess.
This is the kind of thing that Linux has to put up with to be all things to all people. And totally unecessary.
Linus does Linux because Linus enjoys doing Linux. Windows sales are not relevant to him.
I saw Windows for sale in an Office shop the other day - $445 (cough, splutter), and not a bit of interesting character either!
This is actually a really good thing for the Android home-brew ROM scene. At the moment you have the kernel (boot.img) and the OS (system.img). If the boot image can be standardised across phones, without having to wait for the individual phone manufacturers to release the source, ROMs can be ported a whole lot quicker.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
