Forgot your password?
typodupeerror
Open Source Upgrades Linux

Linux 3.7 Kernel To Support Multiple ARM Platforms 82

Posted by timothy
from the break-a-leg-not-an-arm dept.
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:
  • Re:Unified platform? (Score:3, Informative)

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

    It's called device tree (DT).

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

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

    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.

    [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=11801e9de26992d37cb869cc74f389b6a7677e0e

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

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

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

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

    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 Fedora. No GPU support though.

    For the omap platform, which includes both Beagle and Panda along with a lot of other systems, a lot of work is going into making it work with multiplatform, but it's a lot harder, mostly because of the amount of code that needs to be touched. All fundamental issues have been solved by Linaro though, so 3.8 might be in reach. If not, it will be in 3.9.

    To translate the platform names into something more useful:

    highbank: Calxeda's quad-core server platform, used by HP and others
    mvebu: Marvell's Armada XP quad-core server platform, used by Dell and others
    vexpress: ARM's reference design, used for KVM and Xen guests
    socfpga: Altera's FPGA platform, not too important
    picoxcell: Wireless base station processors from picochip. Nevermind.

    Also in 3.8, we should gain multiplatform support for Freescale i.MX (if that doesn't make it into 3.7 last minute) and ST-Ericsson's NovaThor (u8500) processor that is used in a number of Android phones. Samsung Exynos and Qualcomm MSM will take a lot longer probably.

It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence. - W. K. Clifford, British philosopher, circa 1876

Working...