There appear to be three substantive issues:

1.  The bootloader and booting methodology (something MS wanted to 
change on X86-64 platforms with the advent of MS Win 8 so that, 
effectively, MS non-certified environments would not be allowed to boot 
on platforms that MS certified for MS Win 8 -- nominally, a "security" 
measure, but in reality, a MS monopoly profiteer measure).

2.  Device drivers (including any relevant bus issues) -- even today, 
there are some PCI and other devices for X86-64 for which the device 
vendor has released no USA hardware compatible driver specifications and 
that have not been reverse engineered to work with Linux.  Evidently, 
this situation is more pervasive with ARM platforms.

3.  Obtaining standard Linux end-user applications for ARM ISA 
platforms.  For example, there is a rather stripped version of Mozilla 
Firefox for ARM Android platforms, but no Mozilla Thunderbird nor 
Lightning.  Likewise, one uses something such as Busybox to provide a 
subset of regular open systems utilities -- an impressive and growing 
subset, but not full functionality.

The peculiar thing is that -- internally -- Android does use a Linux 
kernel -- but not any sort of typical standard linux end user 
environment (e.g., a very limited GUI compared with something like KDE 
under X11, and the applications available thereunder).  In part this is 
because of the limited RAM of an ARM platform, but I suspect that there 
were other deliberate incompatibility decisions made for market sector / 
business / profiteer purposes.

Yasha Karant

On 12/08/2012 05:17 PM, Joseph Areeda wrote:
> I'm pretty sure there are Debian ports for ARM including RasberryPi.
> Here's an interesting project out of the UK
> http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64
> node cluster using Lego for the supports.
>
> I'm also sure it was a lot of work like others have mentioned.
>
> Perhaps when the upstream providers get the kernel and the drivers going
> in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM
> also.
>
> Joe
>
> On 12/07/2012 11:27 AM, Konstantin Olchanski wrote:
>> Please do not confuse 3 separate issues:
>>
>> 1) Linux userland: this is pretty much universal and will
>>     run on any CPU as long as you have a cross-compiler
>>     and as long as the "autoconf" tools do not try too hard
>>     to prevent you from cross-compiling the stuff.
>>
>> 2) Linux kernel: is also pretty much universal and assumes
>>     very little about the CPU. There *is* some assembly code
>>     that needs to be ported when you move between CPUs (say
>>     from hypothetical SuperARM to hypothetical HyperARM). I believe
>>     current versions of Linux kernel have this support for
>>     all existing ARM CPU variations.
>>
>> 3) Linux device drivers: in the PC world devices are standardized
>>     around the PCI bus architecture (from the CPU, PCIe looks like PCI,
>>     on purpose) and most devices drivers are universal, so if you
>>     have a PCI/PCIe based ARM machine with PC-type peripherals ("South
>> Bridge",
>>     ethernet, video, etc), you are good to go. If you have an ARM machine
>>     with strange devices (i.e. the RaspberryPI), you have to wait
>>     for the manufacturer to release the specs, then you can write
>>     the drivers, then you can run Linux. Rinse, repeat for the next
>>     revision of the CPU ASIC (because they moved the registers around
>>     or used a slightly different ethernet block). It helps if you have
>>     some standardized interfaces, for example on the RaspberryPI you have
>>     standard USB, so you can use "all supported" USB-Wifi adapters
>> right away.
>>
>> 4) boot loader: is different for each type of machine, each type
>>     of boot device media. period. (Even on PCs there is no longer any
>>     standard standard - some use old-school BIOS booting, others use
>> EFI boot,
>>     some need BIOS/ACPI help, some do not).
>>
>> This makes it 4 issues, if you count the first (linux userland)
>> non-issue.
>>
>>
>> K.O.
>>
>>
>> On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote:
>>> On 10/23/2012 12:37 PM, Konstantin Olchanski wrote:
>>>> An "ARM platform" does not exist.
>>>>
>>>> Unlike the "PC platform" where "PC hardware" is highly standardized
>>>> and almost any OS can run on almost any vendor hardware,
>>>> the "ARM platform" is more like the early Linux days where instead
>>>> of 3 video card makers there were 23 of them, all incompatible,
>>>> all without Linux drivers. If you had the "wrong" video card,
>>>> too bad, no soup for you.
>>>>
>>>> In the ARM world, there is a zoo of different ARM processors,
>>>> all incompatible with each other (think as if each Android device
>>>> had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 -
>>>> the variation in capabilities is that high).
>>>>
>>>> Then each device contains random i/o chips connected in it's own
>>>> special way - there is no PCI/PCIe bus where everything is
>>>> standardized.
>>>> There are several WiFi chips, several Bluetooth, USB, etc chips. Some
>>>> have Linux drivers, some do not.
>>>>
>>>> As result, there is no generic Linux that will run on every ARM
>>>> machine.
>>> Not to be argumentative, but I always believed that the advantage of
>>> *nix* was that it could be ported to numerous platforms, regardless
>>> of hardware.  You even mention the "early Linux days," when there
>>> was little or no standardization of PC hardware.  Yet, the platform
>>> didn't disappear from use simply because there might have been
>>> porting issues, most of which were caused more by proprietary
>>> secrets and hardware defects than the ever-present fact of diversity
>>> of hardware.
>>>
>>> But one could make the same argument even today:  That there are
>>> many different CPU platforms, e.g., and that they are not
>>> standardized.  One example I am thinking of is the Intel v. Amdahl
>>> CPU compatibility issue.  Even though most of the Linux system will
>>> run on either without modification, there are still some unique
>>> issues to each of them; from having worked and studied VirtualBox,
>>> there are differences in how each manufacturer chose to implement
>>> the ring structure that permits virtualization to work as nicely as
>>> it does on these platforms.  For the most part, they are compatible,
>>> but the kernel developers have to be aware of certain implemention
>>> issues, including a bug in the Intel CPU platform that requires a
>>> VirtualBox workaround (for optimizing the code or something; I
>>> forget).
>>>
>>> And this is in addition to Linux supporting umpteen different
>>> processing platforms besides the x86 types.  New hardware appears
>>> constantly, and some Linux user somewhere wants to use it on their
>>> system.  I feel that variety of hardware and variation in hardware
>>> implementation is a fact, and a main reason why Linux and Unix are
>>> so powerful and ubiquitous.
>>>
>>> Now I just hope no one will hold me to this and insist that I
>>> actually port Linux to all these different hardware configuration!
>>> I'm not signing up; I'm just pointing out what I think is reality.