Become a fan of Slashdot on Facebook


Forgot your password?
Open Source Upgrades Linux

Linux 3.7 Kernel To Support Multiple ARM Platforms 82

hypnosec writes with news that the Linux 3.7 kernel will support multiple ARM-based System on Chip platforms (Git commit page), writing "Up until now there has been a separate Linux kernel build for each of the ARM platforms or SoCs, which is one of the several problems when it comes to ARM based Linux. The merging of ARM multi-platform support into Linux 3.7 will put an end to this problem, enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart."
This discussion has been archived. No new comments can be posted.

Linux 3.7 Kernel To Support Multiple ARM Platforms

Comments Filter:
  • Gil Hamilton is one of Larry Nivens best characters

  • by Penguinisto ( 415985 ) on Thursday October 04, 2012 @04:49PM (#41552993) Journal

    So... anyone thinking of tinkering with a kernel that supports the Apple ARM chips?

    (been a long while since I bothered with ARM, so maybe something out there already works with it... dunno. Still, it'd be hella funny to walk around with an iPad that sports a Linux distro on it :) )

    • I suspect that the scale of any processor/peripheral level weirdness(particularly if you are willing to accept values of 'works' that are closer to 'boots' than to 'runs with native performance') is relatively minor compared to the "designed only to run code signed by somebody other than you" problem. Bootloader locks aren't perfect, and have been circumvented on at least the older iDevices; but they certainly make portability a challenge.

    • Are the specs of the A4, A5, A6 even open that Linux can be ported there? I believe that they are genuine Apple only platforms. Although Apple could have achieved the same w/ PPC as well.
      • by Anonymous Coward

        The ARM CPU itself is likely bog standard Cortex, And the GPU most likely Mali. Question is what other stuff is hiding around the SoC, and how to bring it all up in a stable manner. One of the decidedly beneficial things that MS mandates for their RT variant of WIndows 8 is that even ARM based products need to provide PCI device lookup capability. This is usually lacking on ARM SoCs, so there is no way to probe a bus and get a enumerated list of what is on it. You either know what is on there beforehand or

  • “it is now possible to build one kernel that contains support for highbank, vexpress, mvebu, socfpga, and picoxcell. More platforms will be convered over in the next few releases."

    What does that mean? I'm interested in Beagle/Panda variants and Raspberry Pi. The above quote doesn't yield any keyword hits in my wetware.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      The basic infrastructure for supporting bcm2835 (the board used by raspberry pi) was just added a few days ago [1], so maybe 3.7 won't be fully functional on the pi, but it's getting there, I believe/hope.


    • Re:Clue wanted (Score:5, Informative)

      by Anonymous Coward on Thursday October 04, 2012 @05:16PM (#41553193)

      Those are different ARM based SoCs ("System on a chip"). The problem with the ARM platform is that ARM is not really a platform: The unifying aspect is the line of CPUs in the chip, but the SoCs come with different sets of peripherals. Even simple things like what GPIO (General Purpose IO) is connected to what LED or other function require a completely separate hardware configuration compiled into the kernel. On a PC, the kernel uses the BIOS and self-describing hardware to set everything up and choose the right drivers. No such thing exists on ARM. The kernel has to be told manually what's where. That's why you can't currently take a kernel which is compiled for one ARM SoC and use it on a different kind of ARM SoC. You're lucky if you can use the same kernel on the same ARM SoC in a different device that just happens to have everything wired up slightly differently. You may find that the GPIO that turns on the power LED on one system turns off USB power on another system. Then you need to patch the kernel or, if you want to have mainline support, register a new arc number and have yet another configuration added to the kernel. It's a fucking mess.

      • Sounds like the ARM platforms could use a HW API that the kernel could query on boot to know what's where. In fact that sounds like a much better architecture than x86 + "self describing HW" + BIOS - just the "self describing HW" that the kernel reads instead of using a BIOS.

        • by Kurlon ( 130049 )

          A big chunk of achieving a multi-soc supporting linux kernel has been converting arm drivers to use Device Tree for initialization. You build a generic kernel, and uboot either loads a DT or supplies it directly to tell the kernel what hardware layout is present.

    • Re:Clue wanted (Score:5, Informative)

      by jimicus ( 737525 ) on Thursday October 04, 2012 @05:22PM (#41553229)

      In plain English, an ARM processor isn't a chip you can go out and buy from ARM Ltd. It's a processor design (or rather a family of processor designs) you can license from ARM Ltd, re-engineer it to suit your needs if you so choose then fabricate.

      If you want a ready-to-go chip, you have to buy it from someone else who's already done that. Broadcom have done so, and it's one of their chips in the Raspberry Pi, but so have lots of other companies.

      As a result, there's a whole lot of subtly different variants out there. Not all of them are 100% binary compatible with each other. I haven't been able to find out exactly which variant is used in the raspberry pi.

      • As a result, there's a whole lot of subtly different variants out there. Not all of them are 100% binary compatible with each other. I haven't been able to find out exactly which variant is used in the raspberry pi.

        FTFF [], The SoC is a Broadcom BCM2835 []. This contains an ARM1176JZFS [], with floating point, running at 700Mhz, and a Videocore [] 4 GPU. (links mine)

        • by jimicus ( 737525 )

          Yeah, I got that far. I just couldn't figure out whether that made it a highbank, a vexpress, a mvebu, a picoxcell or something else entirely.

          • What this whole experience has taught me is AVOID BROADCOM, because they are going to hold onto every line of code and every driver until the end, and if you're not buying a million units fuck you.

            • by jimicus ( 737525 )

              That's pretty endemic in the embedded industry.

              It's amazing how terrible support in the mainline Linux kernel is for ADSL chips and PPPoA when you consider that the great majority of ADSL routers on the market today run Linux.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      The story for Raspberry Pi is twofold: On the one hand, broadcom are not actively working with the upstream Linux community and everyone runs a forked kernel that is quite different from upstream, so this is not helpful. On the other hand, Stephen Warren (the Tegra maintainer from NVIDIA, but on his own time) just contributed the start of a port to the raspi upstream that will definitely be included in multiplatform in 3.8, and there will soon be patches on top of 3.7 that might get merged into Debian and F

    • Today I can plug my USB hard disk (salvaged from a laptop) into pretty much any PC made in the last decade and have it boot 32bit Linux.

      Provided each device supports a chained bootloader to boot off USB, today's announcement paves the way for similar for ARM hardware e.g. BeagleBoard/RPi/Galaxy Nexus etc.

      Another application would be rescue disks - boot from an SD card from any Android device (supporting booting off SD)

    • I'm guessing they did the simple and therefore relatively easy (but unfortunately not hugely useful because the complex ones are what most people use) platforms first.

      So in other words for most users this doesn't mean much YET but now the framework is in-place hopefully other platforms will follow and in the future linux distros will be able to ship one kernel for most popular arm devices. Having said that it depends critically on getting the drivers to actually make those platoforms work properly merged in

    • I bought a BeagleBoard xM. I have not been able to get much use out of it. When I had the thing working, it was quite slow, and its graphics were relatively low res. Mostly though, I've struggled with the 8G Micro SD card I got for it. The card works just well enough to boot an Ubuntu ARM installation, most of the time, but not to use it for long before some data error causes a crash.

      Maybe I got a bum SD card. But this experience has me thinking that SD cards aren't good enough to replace the classic

  • by amorsen ( 7485 ) <> on Thursday October 04, 2012 @04:53PM (#41553033)

    It happened again, Linus flaming people gets stuff done.

    It all started a year and a half ago with this innocent-sounding topic: [GIT PULL] omap changes for v2.6.39 merge window [].

    Of course it helped that most of the developers in the ARM community seemed to agree with the point Linus made. Other concerns had just taken priority.

    • by Anonymous Coward

      I like his approach - just like I admire Theo De Raadt of BSD fame -> []

      * Since in today's B.S. "Politically Correct World", it takes courage to SPEAK YOUR MIND, plainly & truthfully (not "mincing words") - call a spade, a spade.

      (It is apparently VERY effective... I saw what Mr. T. did vs. NVidia & they ended up doing the right thing so far, @ least afaik, for drivers on Linux!)...

      Now, there's nothing WRONG with being polite, but...

  • by Anonymous Coward

    If I understand correctly, the problem has been that there is no common and open standard for ARM platforms, so each chip has its own hardcoded pins and addresses that the kernel must include.

    Is there any progress on an open specification that SoC designers can implement to get out-of-the-box kernel support?

    • Re: (Score:3, Informative)

      by Anonymous Coward

      It's called device tree (DT).

    • by dgatwood ( 11270 )
      For devices that lack a proper device tree, that's what a config file is for. None of that should be hard-coded into the kernel binary or the source.
    • by Anonymous Coward

      Every phone manufacturer does not create its own radio circuits from scratch. Same with GPU cores, memory devices, etc. Those are licensed from others. Their arrangement on a given SoC varies among manufacturers, but there is much in common and no reason, other than effort, the software drivers can't be made into loadable and configurable modules.

      Linux ARM developers are making the common drivers into dynamically loadable modules so they can be loaded and configured at boot just like a traditional x86 ke

      • An ARM SoC is not conceptually different than a PC full of peripherals. It just happens that ARM SoCs have the devices physically integrated into the SoC package.

        The big difference is on a modernish* PC pretty much all perhierals are either

        1: Of a "standard" type and in well-known "standard" locations in the IO or memory address space
        2: On a bus that looks to software like PCI
        3: On some other discoverable bus or interface behind a controller that sits on a bus that looks to software like PCI

        So In a PC you know where some stuff is from the start and you find the rest by enumerating the PCI bus(es) thorough the PCI configuration space (which is accessed through a well

    • by tlhIngan ( 30335 )

      If I understand correctly, the problem has been that there is no common and open standard for ARM platforms, so each chip has its own hardcoded pins and addresses that the kernel must include.

      Well, ARM is just the processor core. An ARM SoC consists of the core plus more useful peripherals, like a memory controller (so you can have well, memory), serial ports, USB controllers, display controllers, etc.

      Thing is, these things exist all over the memory map - put wherever the IC designers felt they should go.


  • Once they unify ARM kernels, the Zedboard [] PC featuring the Xilinx Zynq [] ARM/FPGA CPU should see even more and better development.

    I'd love to see some porting of kernel functions into the FPGA, custom instructions that the kernel could execute in a flash rather than churn ARM cycles through. Is there a list of kernel bottlenecks that could be candidates for that kind of acceleration?

    • by Anonymous Coward

      The Zynq platform will be relatively easy to add to this list, it already does everything necessary for multiplatform, except using the common clock distribution framework, but the hardware also doesn't do a lot of clock management. Note however that the kernel you get from Xilinx has a lot of patches that are not even part of the mainline kernel, so if you rely on any of their patches, things look a lot worse.

      • I was actually thinking of using the Xillinux [] (customized Ubuntu) distro on the Zedboard, since the one bundled with the Zedboard doesn't seem to support a VGA console out of the box, but Xillinux seems to. But I want to keep up with the mainstream kernel updates, not some Xillinux/Zedboard/Xilinx backwater. If one of these distros that include APIs to the FPGA included the mainstream 3.7 kernel, maybe only the userland would depend on upgrades from these third parties.

  • by LordNimon ( 85072 ) on Thursday October 04, 2012 @05:51PM (#41553463)

    enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart

    It would be more accurate to say that is more in line with its PowerPC counterpart, since device tree support is the primary reason why multi-platform works on ARM today, and that support was ported from PowerPC last year. Very few x86 platforms use device trees, but they have been pervasive on PowerPC for over five years now.

  • If kernel 3.7 supports multiple arms, does this finally give me the codec to watch japanese tentacle porn?
  • Does this mean Linus believes Linux on ARM isn't going to be crippled by UFEI?

    • You might be surprised to know that the Linux kernel runs on most smartphones.
    • by gl4ss ( 559668 )

      linux is running on more arm devices than on x86.

      so, no, uefi isn't going to cripple arm usage for companies.

  • ... a year starting with 199...

    (except for Sun-3, which uses a completely different MMU).

  • Sorry for my very stupid question Does this mean, that in theory we would be able to have two different architecture CPU-s, ARM and x86 and be able to use both of them at the same time within the kernel?
    • When you say "both at the same time", I'm not really sure what you're asking. It is my understanding (note that I'm not a Linux guru by any count) that this will primarily make porting the kernel to ARM platforms a lot easier for developers (currently most ARM kernels are forked from the mainline linux branch) and, possibly, it means having to ship just one kernel for multiple ARM architectures instead of individual ones (Which should make life a lot easier for say the likes of HTC who typically have multip

      • Let me rephrase my question
        Take for example you have a motherboard with 2 cpu-s one arm and the other would x86. Would it be possible to run applications compiled for different cpu architectures at the same time (with this change to the kernel) ?
        • ...does such a motherboard exist? (Seriously, does it? Because that would be cool). ...I'm going to hazard a guess and say "no", though. Possibly different ARM chips but I doubt it'll let x86 and ARM run side-by-side...but then again, what do I know?

          • I'm not aware of a such motherboard, as you said it would be cool if such a thing existed. I was just wondering.

            • Perhaps not a motherboard, but I dare say it could be done as some sort of addin card? I don't know how that changes things, what with having to set up a "host" CPU that handles the PCI bus, then setting up the ARM CPU afterwards'd still be cool!

              • It would be a great add-on card, but I assume (I have no idea of engineering stuff) it would be very difficult to build one, at least at the level of usage we are talking about.
                Direct access to ram, hdd etc. a parallel cpu with different architecture, but of same importance. I assume it could be used in a lot of industry fields.
          • Yes it does exist, for example ThinkPad X1 Hybrid. And no, this update won't allow them to be used simultaneously, that is a separate issue that is not addressed here.

Money is better than poverty, if only for financial reasons.