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

[Adarion]

Good to see some unification in terms of ARM. Last year there was a nearly whole track of lectures (Saturday morning til early afternoon) on the Chemnitz Linux-Days, and most of them were about ARM and all the developers mentioned the mess that the ARM platforms were. So this is probably a very good step in the right direction.

[MaxToTheMax]

Probably not feasable with Pi1 not having hard float.

That affects userspace, but the kernel developers have a policy of never using floating point IIRC.

[SystemCrasher]

Does that mean the Raspberry Pi 2 will be able to boot and run without any proprietary blobs/firmwares/etc?

Highly unlikely. As far as I understand, it basically boots like this on power-up:
1) GPU (!!!) takes control using on-chip ROM.
2) It loads some extra GPU (!!!) boot code, which is blob-only and uses uncommon instruction set. Boot ROM expects FAT32, so good luck to use something else.
3) This GPU code inits DRAM, loads some extra parts and so on. There're several stages.
4) Finally, ARM cpu started and given code loaded ftom FAT32 by GPU.

So, you have to live with FAT32, and GPU blobs in boot sequence, these come without source. And even if there was source, it is exotic command set, not ARM code. And even then you can't get rid of FAT32. Not to mention it would be really unusual move for someone like Broadcom to release sources of their blobs.

Broadcom are really creative ppl. On most other things, this done by ARM CPU itself and there're usually much less restrictions on filesystems and that early boot code comes with source. Actually, u-boot provides special facilities to create early init code, including running in system where no DRAM available yet from small pre-loader (they call it SPL). Once it brings up DRAM, it loads larger main part of u-boot, which can do smarter things or just Linux kernel (from fixed location, which is not flexible but easy to do from small code). But it's not about PIs. They can launch u-boot, but only as chainload from bunch of their blobs, and blobs are mandatory.

[name99]

A very strong claim in those parentheses. It's also unsubstantiated.

Why would a common low-level specification cost ARM? Is it because the big corps wouldn't obey it anyway? Go their own route? That wouldn't make much sense, considering UEFI somehow manages to exist. This giant ARM rework seems to be indicative of a large desire, seemingly mutual among the big corps that contributed, for booting an upstream kernel, as opposed to doing the bare minimum on the low-level and tossing an Android VM on top. Much simpler to just have a spec already lined up as opposed to doing the leg work yourself.

If ARM created a unifying low-level spec for firmware initialization and it just so happened to bite them in the end, then what would it cost them?



Which is clearly why ARM would have nothing to lose by developing a unified boot spec. The big corps do literally zero work outside of implementing it. They have everything to gain and nothing to lose (outside of not being able to do what Intel already does with its creepy low-level WiFi guff should ARM not go that route, but I digress).

You seem to be arguing against a non-problem.
ARM is not somehow against a unified boot spec. They sponsored Linaro and are intimately aware of the problem --- and have worked to solve it.
They have this all lined up for ARMv8 (UEFI and ACPI specs); the problem is that these boards are legacy. ARM has no incentive to try to retrofit something into this space because by the time they are done, the new versions of these boards will all be running A35's and the A35 successors.

[name99]

A very strong claim in those parentheses. It's also unsubstantiated.

Why would a common low-level specification cost ARM? Is it because the big corps wouldn't obey it anyway? Go their own route? That wouldn't make much sense, considering UEFI somehow manages to exist. This giant ARM rework seems to be indicative of a large desire, seemingly mutual among the big corps that contributed, for booting an upstream kernel, as opposed to doing the bare minimum on the low-level and tossing an Android VM on top. Much simpler to just have a spec already lined up as opposed to doing the leg work yourself.

If ARM created a unifying low-level spec for firmware initialization and it just so happened to bite them in the end, then what would it cost them?



Which is clearly why ARM would have nothing to lose by developing a unified boot spec. The big corps do literally zero work outside of implementing it. They have everything to gain and nothing to lose (outside of not being able to do what Intel already does with its creepy low-level WiFi guff should ARM not go that route, but I digress).

You seem to be arguing against a non-problem.
ARM is not somehow against a unified boot spec. They sponsored Linaro and are intimately aware of the problem --- and have worked to solve it.
They have this all lined up for ARMv8 (UEFI and ACPI specs); the problem is that these boards are legacy. ARM has no incentive to try to retrofit something into this space because by the time they are done, the new versions of these boards will all be running A35's and the A35 successors.

[name99]

A very strong claim in those parentheses. It's also unsubstantiated.

Why would a common low-level specification cost ARM? Is it because the big corps wouldn't obey it anyway? Go their own route? That wouldn't make much sense, considering UEFI somehow manages to exist. This giant ARM rework seems to be indicative of a large desire, seemingly mutual among the big corps that contributed, for booting an upstream kernel, as opposed to doing the bare minimum on the low-level and tossing an Android VM on top. Much simpler to just have a spec already lined up as opposed to doing the leg work yourself.

If ARM created a unifying low-level spec for firmware initialization and it just so happened to bite them in the end, then what would it cost them?



Which is clearly why ARM would have nothing to lose by developing a unified boot spec. The big corps do literally zero work outside of implementing it. They have everything to gain and nothing to lose (outside of not being able to do what Intel already does with its creepy low-level WiFi guff should ARM not go that route, but I digress).

You seem to be arguing against a non-problem.
ARM is not somehow against a unified boot spec. They sponsored Linaro and are intimately aware of the problem --- and have worked to solve it.
They have this all lined up for ARMv8 (UEFI and ACPI specs); the problem is that these boards are legacy. ARM has no incentive to try to retrofit something into this space because by the time they are done, the new versions of these boards will all be running A35's and the A35 successors.