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. -- CONFIG_NEON=y causes platform lockups with certain application/platform combinations https://bugs.launchpad.net/bugs/507416 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
