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 ;-) -- Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko Canonical Ltd. | [+55 16] 9112 6430 | http://async.com.br/~kiko _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
