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.


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.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada