A Massive ARM v6/v7 Rework Is Landing With Linux 4.5 Plus Raspberry Pi 2 Support

[phoronix]

Phoronix: A Massive ARM v6/v7 Rework Is Landing With Linux 4.5 Plus Raspberry Pi 2 Support

With the Linux 4.5 kernel the ARMv6/ARMv7 platforms are now multi-platform after five years of work...

http://www.phoronix.com/scan.php?page=news_item&px=ARM-Linux-4.5-Changes

[dragonn]

I am dreaming of a day where ARM will be compatible like x86 platforms, maybe it comes closser now?

[schmidtbag]

I am dreaming of a day where ARM will be compatible like x86 platforms, maybe it comes closser now?

I was thinking the same. It's ridiculous how long it's taking. Though there may be some huge technical hurdle, I find it really hard to believe that it would be this complicated.

I think the kernel change mentioned in the article is a good step forward, but unfortunately it seems ARMv8 wasn't involved.

[RSpliet]

I was thinking the same. It's ridiculous how long it's taking. Though there may be some huge technical hurdle, I find it really hard to believe that it would be this complicated.

Well, not necessarily complicated. Keep in mind that ARM devices don't come with a BIOS nor with a probable bus. This means that previously for every SoC and even board there had to be a separate code base. Converting *all* of that to a more sustainable and code-sharing-friendly architecture (which now uses the "device tree" as an alternative to hard code and device probing methods) is just a mountain of work.

I think the kernel change mentioned in the article is a good step forward, but unfortunately it seems ARMv8 wasn't involved.

I only assume that ARMv8-based kernel support has been "multiplatform" from the beginning.

[oxwivi]

Raspberry Pi 2 SoC support is all well and good, but does the same code support Pi 1 as part of ARMv6? Provided that Ubuntu builds on this codebase, will Canonical have any excuse to not support both Pi 1 and 2 with the same image?

[willmore]

I agree that this is both necessary and a long time coming, but the ARM processor world is vastly different than x86. In x86, there are only a few players and they generally follow each others lead. In the ARM world, there are dozens of different companies making processors (SoC's really) and each one only cares about selling their chips to their customers. The customers only care if their one little device works. There is no incentive for them to coordinate their work by upstreaming patches, organizing them logically, etc.

So, solving this issue is either (inclusive or):
1) Someone holding a strong whip hand to force the companies in like (ARM could do this if they cared, but it would cost them)
2) Someone going through all the many, many GPL compliance code dumps all over the internet and trying to make a sense of them by bringing them into some kind of orginization.

Regardless of which path is taken, there will be a point where it's easier for the users of these chips to 'fall in line' with the kernals new way of doing things and integrating those changes should get easier. It'll become easier and easier to 'just make it work' and to 'do it the right way' at the same time.

So, this is change is necessary, important, and difficult as hell. So, thank you for your hard work, Arnd and Olof--and all of the others not named.

[willmore]

I only assume that ARMv8-based kernel support has been "multiplatform" from the beginning.

I sure hope so.

[schmidtbag]

Well, not necessarily complicated. Keep in mind that ARM devices don't come with a BIOS nor with a probable bus. This means that previously for every SoC and even board there had to be a separate code base. Converting *all* of that to a more sustainable and code-sharing-friendly architecture (which now uses the "device tree" as an alternative to hard code and device probing methods) is just a mountain of work.

Understood - I'm aware of the things you mentioned, but there are very simple solutions for that. For example, the kernel could come with all [open source] drivers for all ARM platforms, and there could be a very early-stage init script (maybe even implemented into uboot or whatever) of some sort that loads a config file (such as uEnv.txt) custom to whichever platform you're using. This would define how each piece of hardware is handled. I don't see why something like that would be hard to implement. Everyone could use the same kernel build, each distro could supply one generic disk image, and all users have to do is copy some config file that specifies what their platform has and how it should behave. But like I said, if it were that simple it should've been done a long time ago. I'm guessing there's something much more complicated that is getting in the way, because to me this solution is a little too obvious.

I do understand, however, that some of the closed-source drivers may severely complicate this.

I only assume that ARMv8-based kernel support has been "multiplatform" from the beginning.

So I've heard, but I have yet to see much proof of that yet. Then again, I haven't really looked into it that deeply.

[AJenbo]

I sure hope so.

Probably not feasable with Pi1 not having hard float.

[droidhacker]

Probably not feasable with Pi1 not having hard float.

Well, since rpi1 (and 2 for that matter) are NOT armv8, your response really is completely meaningless.