Linux 3.7 Kernel To Support Multiple ARM Platforms

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

Comments

Odd question - Apple A4?

[Penguinisto]

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 :) )

Re:Odd question - Apple A4?

[elfprince13]

Like....this?

Re:Odd question - Apple A4?

[fuzzyfuzzyfungus]

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.

Re:Odd question - Apple A4?

[unixisc]

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.

Re:Odd question - Apple A4?

[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 you're out of luck.

Clue wanted

[dbc]

“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:Clue wanted

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

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

Re:Clue wanted

[Anonymous Coward]

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

[jimicus]

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

[Doc Ruby]

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.

Re:Clue wanted

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

Re:Clue wanted

[Kurlon]

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

[ChunderDownunder]

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)

Re:Clue wanted

[drinkypoo]

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)

Re:Clue wanted

[petermgreen]

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 into the upstream kernel as well.

Also the Pi is a bit of a weird case since it's armv6+vfpv2, this means that those wanting good performance on the Pi will likely have to stick with distros where the whole distro (not just the kernel) is compiled with the the Pi in particular in mind since afaict most regular hardfloat distros have picked armv7-a+vfpv3_d16 as their minimum CPU target. There don't seem to be many other armv6 devices that are popular in the hobbyist community (the only armv6 devices i'm personally aware of are the Pi, the via APC and some low end smartphones).

Re:Clue wanted

[bzipitidoo]

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 spinning hard drive.

Re:Clue wanted

[amorsen]

As a nice turn of events, the platform maintainer is actually working for NVIDIA, not for Broadcom. Shows you who is open source friendly and who isn't these days.

That actually seems to be a bit of a trend -- nVidia engineers doing spare time open source work on non-nVidia platforms. It ensures that they cannot be accused of leaking nVidia secrets in the code.

Whether it shows anything about who is open source friendly, and what exactly it shows, is less clear to me...

Re:Clue wanted

[jimicus]

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.

Re:Clue wanted

[drinkypoo]

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.

Re:Clue wanted

[jimicus]

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:Clue wanted

[Doc Ruby]

That is how a product dies: laden with lockin, leveraging only the installed base instead of more interoperation. Meanwhile ARM and Android/Linux is installed on over 500 million mobile devices (plus a lot of servers and workstations), rapidly outgrowing the 900 million Windows installs (plus a pitiful few phones), to say nothing of the even worse loss by MS in embedded devices.

If MS could turn the lockin to lockout of upgrade with Android or Linux, it might keep another tentacle attached, but it all starts to look like the changing of the mainframe guard that MS rode to victory for so long.

Linus flaming gets job done

[amorsen]

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.

Unified platform?

[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:Unified platform?

[Anonymous Coward]

It's called device tree (DT).

Re:Unified platform?

[dgatwood]

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.

Re:Unified platform?

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

As for the need for a specification; ARM already specifies how devices appear in the address space and how interrupts and other resources are used by devices. That should be all the specification needed.

Re:Unified platform?

[tlhIngan]

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.

It's nice to consolidate, but I can't see how far they can go - because stuff like main memory can exist at many different locations in the memory map.

Unlike say, the x86, whose basic platform design remains unchanged since the 80s. Sure chips have consolidated and such, but they all boot the same way - you can expect the BIOS in the same spot, memory to be somewhere else (with a gap), the PCI controller is at the same location, basic VGA video, etc.

Re:Unified platform?

[MightyMartian]

A Device Tree description is a helluva easier to roll out than a newly compiled kernel for every device. I agree it's not ideal, but the ARM ecosystem is a bloody complicated one, and it's likely the best we can expect until that little piece of the Wild West is tamed. And maybe it never will be, as the attraction of ARM is precisely in its non-one-size-fits-all way of doing things.

If I'm looking at porting my kernel and software stack to some new ARM device, I'll take some comfort in the fact that the bulk of getting it running will be a spec file, and not having to do a kernel configure and compile. I've wasted enough hours of my life doing that sort of thing.

Re:Unified platform?

[petermgreen]

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 known location in the IO address space). Then in turn enumerating any buses or interfaces you find controllers for on the PCI bus.

While afaict on most arm systems there are no such enumeration features and even if there were (a few arm devices DO have PCI) there is no standard on how to access them. So the infromation has to be provided to the kernel by other methods. Traditionally it was just built into the kernel but this has made it very difficult for general purpose linux distros to properly support arm. So there has been a push to providing it externally from the bootloader "device tree" and thus moving towards a world where arm kernels are no longer device specific.

* Basically any PC that doesn't have ISA cards in it.

How About ARM/FPGA Zedboard?

[Doc Ruby]

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?

Re:How About ARM/FPGA Zedboard?

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

Re:How About ARM/FPGA Zedboard?

[Doc Ruby]

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.

Re:How About ARM/FPGA Zedboard?

[Doc Ruby]

Xillinux and other distros seem to work on the Zedboard (perhaps better than Xilinx's). I'd think they'd rather use the mainstream kernel, with the Xilinx patches for the FPGA HW. I'll ask Xillybus.

Re:Obligatory Niven reference

[Doc Ruby]

All the wireheads have been jonesing for multiple this kernel update.

More like PowerPC

[LordNimon]

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.

Good for Mr. T.!

[Anonymous Coward]

I like his approach - just like I admire Theo De Raadt of BSD fame -> http://linux.slashdot.org/comments.pl?sid=3007641&cid=40785151

* 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... you do NOT have to a "politician" (not that well liked or respected, face it, many times) to do so. The world's TOO FULL of that... imo @ least.

APK

P.S.=> I'd shake the guy's hand actually... yes, everyone here KNOWS I am like "the poster boy" for being a Microsoft fan, but... since I 1st tried Linux in 1994 (Slackware 1.02), then Redhat 6.x (1998 iirc), & KUbuntu for ALL OF SUMMER 2010 (on a laptop while I was touring europe)?

It's grown more than Windows has (then again, it had more "room" to grow too, to catch up!)... & when MS "pulled" support for other CPU architectures (even though Intel/AMD really IS the most used overall CPU computing platform there is on personal computers, bar-none (not counting smartphones/cellphones))?

The "penguins" did THE RIGHT THING - & seized an opportunity to put their OS onto a LOT MORE than just PC's &/or Servers... &, it's showing!

(Heck - when I saw ANDROID giving Apple's iOS a "Run for its money"? I was impressed!)

One day, I just *may* become a Linux user, permanently (depends on what happens with Windows 8, & when I can no longer use Windows 7, or rather, have it be supported)...

... apk

Re:Good for Mr. T.!

[neokushan]

Your 0.2% (or whatever it is) desktop marketshare says otherwise.

Re:Good for Mr. T.!

[Lennie]

Between 1% and 2% is generally what people think it is if they look at all the statistics.

Multiple arms...

[wbr1]

If kernel 3.7 supports multiple arms, does this finally give me the codec to watch japanese tentacle porn?

Re:Multiple arms...

[JoeCommodore]

I, for one, welcome our new multiple armed platform overlords.

Here is a thought

[sgt scrub]

Does this mean Linus believes Linux on ARM isn't going to be crippled by UFEI?

Re:Here is a thought

[Jello B.]

You might be surprised to know that the Linux kernel runs on most smartphones.

Re:Here is a thought

[gl4ss]

linux is running on more arm devices than on x86.

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

Cool! M68k had this since...

[geert]

... a year starting with 199...

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

Probably stupid question

[flakron]

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?

Re:Probably stupid question

[neokushan]

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 multiple smartphones on the market - each with its own kernel, eventually this means they'll be able to have one super kernel that handles them all).

Or so I think.

Re:Probably stupid question

[flakron]

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) ?

Re:Probably stupid question

[neokushan]

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

Re:Probably stupid question

[flakron]

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

Cheers

Re:Probably stupid question

[neokushan]

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 but....it'd still be cool!

Re:Probably stupid question

[flakron]

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.

Re:Probably stupid question

[connect4]

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.

From scratch...

[unixisc]

Speaking of which, anybody know whether there is a BSD from scratch? A Minix from scratch?

Re:Wake me up when...

[jones_supa]

At least in the photo there seems to be a working platform for LEG.