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."
Re: (Score:2)
Obligatory Niven reference (Score:1)
Gil Hamilton is one of Larry Nivens best characters
Re: (Score:2)
All the wireheads have been jonesing for multiple this kernel update.
Odd question - Apple A4? (Score:4, Interesting)
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: (Score:3)
Re: (Score:2)
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: (Score:2)
Re: (Score:1)
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
Clue wanted (Score:2)
“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)
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: (Score:1)
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 (Score:5, Informative)
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: (Score:2)
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: (Score:1)
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: (Score:2)
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 start
Re:Clue wanted (Score:5, Informative)
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: (Score:2)
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 [raspberrypi.org], The SoC is a Broadcom BCM2835 [broadcom.com]. This contains an ARM1176JZFS [arm.com], with floating point, running at 700Mhz, and a Videocore [wikipedia.org] 4 GPU. (links mine)
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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)
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
Re: (Score:3)
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: (Score:2)
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
Re: (Score:2)
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
Linus flaming gets job done (Score:5, Interesting)
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 [gmane.org].
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.
From scratch... (Score:2)
Good for Mr. T.! (Score:1)
I like his approach - just like I admire Theo De Raadt of BSD fame -> http://linux.slashdot.org/comments.pl?sid=3007641&cid=40785151 [slashdot.org]
* 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...
Re: (Score:2)
Your 0.2% (or whatever it is) desktop marketshare says otherwise.
Re: (Score:2)
Between 1% and 2% is generally what people think it is if they look at all the statistics.
Unified platform? (Score:1)
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)
It's called device tree (DT).
Re:Unified platform? (Score:5, Insightful)
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: (Score:2)
Re: (Score:1)
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
Re: (Score:3)
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
Re: (Score:3)
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
How About ARM/FPGA Zedboard? (Score:2)
Once they unify ARM kernels, the Zedboard [zedboard.org] PC featuring the Xilinx Zynq [wikipedia.org] 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: (Score:1)
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: (Score:3)
I was actually thinking of using the Xillinux [xillybus.com] (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: (Score:2)
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.
More like PowerPC (Score:3)
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.
Multiple arms... (Score:2)
Re: (Score:3)
I, for one, welcome our new multiple armed platform overlords.
Here is a thought (Score:2)
Does this mean Linus believes Linux on ARM isn't going to be crippled by UFEI?
Re: (Score:1)
Re: (Score:2)
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... (Score:1)
... a year starting with 199...
(except for Sun-3, which uses a completely different MMU).
Probably stupid question (Score:1)
Re: (Score:2)
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
Re: (Score:1)
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: (Score:2)
...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: (Score:1)
Cheers
Re: (Score:2)
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: (Score:1)
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: (Score:1)
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.