On Mon, 10 Dec 2012, Konstantin Olchanski wrote:

> On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote:
>> I'm pretty sure there are Debian ports for ARM including RasberryPi.
>
>
> I am more interested in getting the SL userland running on the ARM machines.
>

There is a RHEL 6 rebuild for "arm" called RedSleeve. 
http://www.redsleeve.org .

-Connie Sieh

>
> K.O.
>
>
>
>
>>
>> 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.
>
>