| |||||||||||||
LFCS: ARM, control groups, and the next 20 yearsLFCS: ARM, control groups, and the next 20 yearsPosted Apr 13, 2011 21:17 UTC (Wed) by drdabbles (subscriber, #48755)In reply to: LFCS: ARM, control groups, and the next 20 years by cpeterso Parent article: LFCS: ARM, control groups, and the next 20 years
I suspect the important difference between the ARM arch and the x86 arch is that there are gobs of generic x86 systems out there with the same exact cpu in them, and with a roughly equivalent basic bill of materials.
In the arm space, there are loads of custom parts. Custom CPUs, custom boards, etc. Very little is the same across multiple devices, which makes it very difficult to have a generic platform to bless as your standard. In fact, there are still ARM chips in heavy use that have no MMU.
This can most easily be seen by building a defconfig for an x86 system and booting it and trying to build a defconfig for an ARM device.
(Log in to post comments)
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 6:06 UTC (Thu) by james (subscriber, #1325) [Link]
Also, I understand that most of the x86 platform has discoverability built in, so various OSes (possibly user-installed) can work out what's in the system and how to use it. On most ARM systems, that's an unnecessary expense and power draw, since it can be hard-coded in the highly-constrained software environment.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 13:24 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
ARM keeps tighter control of their architecture than Intel has ever been able to with x86. Very few commercial ARM cores have been designed outside of ARM. The problems are mostly outside the CPU, and they lie not so much in customisation (though there is much apparently pointless wheel-reinvention) but in lack of discoverability.
Most platforms have basic devices like an interrupt controller and interval timer that can just be assumed to be present. On x86 you get a PIC or APICs and a PIT or HPET. The newer versions even have backward-compatible modes. On ARM there are a wide variety of interrupt controllers and timers, and no reasonable way to probe for them. The boot loader is supposed to tell the kernel which type of machine it's booting on, and sometimes the system vendor even gets this right... but AFAIK the kernel isn't yet able to initialise the right set of drivers based solely on that.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 18:54 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
actually, in the discussion on linux kernel it was proposed to make the bootloader pass this information to the kernel, and there was a large amount of opposition from many of the ARM people to this suggestion.
based on this I don't believe that it works that way today.
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 23:28 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
It does work the way I said: the boot loader passes in a machine type number. But the kernel still has to have a built-in definiton of each machine type.
The current discussion is about having the boot loader pass in a fuller machine description (the Device Tree). This may simply be tacked onto the end of the kernel image in some way, so there is no need to modify existing boot loaders.
LFCS: ARM, control groups, and the next 20 years Posted Apr 15, 2011 18:11 UTC (Fri) by p2mate (subscriber, #51563) [Link]
I would argue it's the other way around. There are only 3 companies who can make modern x86 cores: Intel, AMD and VIA. Intel doesn't license the necessary patents to others (besides those 2) to allow them to make x86 cores. Anyone with enough money can buy an ARM architecture license though which allows making your own core. At least the following companies have at some point made their own cores or modified the ones provided by ARM : Digital, Intel, Marvel, Qualcomm, Samsung and more companies are working on new cores.
|
|||||||||||||