Slashdot Mirror
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."
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 :) )
Quo usque tandem abutere, Nimbus, patientia nostra?
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.
Finally! A year of moderation! Ready for 2019?
It's called device tree (DT).
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
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.
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.
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.
--
make install -not war
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.
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.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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)
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I, for one, welcome our new multiple armed platform overlords.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
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.