On Wed, Sep 01, 2010 at 03:56:15PM +0300, Amit Kucheria wrote:
Because it adds a sub-arch, revision-specific override into generic architecture code (vfpmodule.c)
To do this elegantly with a hope to get it to mainline, we'd need a way to disable the hwcap through some board-specific fixup code that can check the revision of the board at runtime.
Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is called too early.
Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Hmm; I would rather we tried a bit harder to find a solution which was workable upstream. I'm surprised there's no generic facility to do fixups of this sort given how fast we've run into the problem -- a hint towards something the KCWG could improve?
We can do that in Linaro, I'm just a bit uncomfortable that there is a non-trivial amount of TO2 devices out there, and it's a DoS issue to have this NEON flaw.
I would be ok if we would only support TO3 and the kernel wouldn't boot on TO2 hardware, but AIUI the kernel will boot just fine and turn on NEON on TO2 such as Babbage 2.x, so I'm a bit scared by just release noting it.
Another solution is that we could perhaps add code in the board init function to check the cpu revision and if NEON was enabled, then stop booting.
That's a backup plan I'd be mildly okay with; I don't like the idea of the Linaro kernel booting on even less hardware ;-)