Michael Weiser michael.weiser@gmx.de writes:
I am *using* it on Cubieboard 2's which are armv7. I don't think there's eveer been an actual hardware support statement.
Question is, what devices are out where, there armv5 support would be useful?
I have tried building Nettle for armv5teb (thinking about NSLU2) and got failures because of `rev` instruction usage (present only on ARMv6/v7).
Lookingup NSLU2 on wikipedia, it seems it features a "Intel XScale cpu" featuring an "ARMv5TE ISA without the floating point instructions." I take it this can be run in BE mode?
Huh, right. Most of the revs are in the v6 and neon subdirectories which should be fine because they are only activated for v6+. So we'd need to eliminate the revs in arm/memxor.asm and arm/memxor3.asm to support armv5teb.
Options are:
1. Do nothing, let armbe assembly require armv6, and recommend --disable-assembly for armv5be.
2. Eliminate use of rev in the armbe code.
3. Somehow arrange in configure so that the memxor files in particular aren't used when targetting armv5be. If you want to test the effects before hacking configure.ac, I think it should be as easy as removing the memxor*.asm symlinks after running configure.
I could dust off the old binfmt_misc setup for armv6veb and give that a whirl if it's of any help. I'm quite certain I initially worked around the asm problems on armeb by disabling asm when cross- and binfmt_misc-qemu-natively-compiling the userland for my Cubies. So I have likely never run the asm under qemu-user nor qemu-system.
Is there some problem with configuring qemu to emulate armv6? I think that's what is used when testing non-BE ARM, but I'm not 100% sure about that.
Regards, /Niels