Comment 20 for bug 507416

It looks like it's possible to implement the additional unaligned access emulation for Thumb-2, but it may involve a non-trivial amount of work.

In particular, loads and stores behave differently for ThumbEE compared with normal Thumb-2. ThumbEE is not much used at present, so it would probably be OK simply to SIGILL in such cases though, without implementing all the emulation for ThumbEE specifically.

A couple of possible ways forward:

1) Currently, I've been working on the assumption that because lucid is mostly Thumb-2 it won't work at all if we turn on aligned access faulting with the current kernel. This might not be true. A couple of things we could try with the current kernel:

   a) Hack the kernel to turn on full unaligned access faulting, run a karmic filesystem (which is ARM, not Thumb-2, and so should work without problems) --- look at the kernel log messages and the fixups counted in /proc/cpu/alignment

   b) Hack the kernel to turn on full unaligned access faulting, run a lucid filesystem --- see whether it works, and whether the kernel generates any log messages about failed alignment fixups.

2) We take a pragmatic approach and consider that lucid only needs to be "as good as" karmic on i.MX51 TO2. If this is considered acceptable, we can simply build with CONFIG_NEON=y and lie about HWCAP_NEON for <=TO2 --- this is actually functionally equivalent to the karmic/lucid configuration from the point of view of userspace, except that well-behaved NEON code becomes usable (which was not previously the case).

We could alternatively use CONFIG_NEON=y ... and dynamically lie about HCWAP_NEON and set ASEDIS for <=TO2. This makes it harder for (non-privileged) user code to cause problems; so this configuration is a bit more robust than jaunty/karmic, at the expense of preventing well-behaved NEON code from working.