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