Hi Niels,
On Sat, Feb 22, 2020 at 07:58:10AM +0100, Niels Möller wrote:
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?
Well, arm devices are quite long-lived. I myself had my Marvel Kirkwood based NASes (which were armv5 but never ran BE) running way longer than I would have kept a similar x86 system around. These were 300Mhz and 128MiB of RAM, so totally underpowered, but they did their job. But with the current hype about aarch64 I'd expect the armv5 installation base to be shrinking.
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?
The Intel XScale and IXP4xx are BE by default, IIRC. For them it's even a bit of a hike to run them LE since all their companion controllers and firmware blobs are BE as well.
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:
- Do nothing, let armbe assembly require armv6, and recommend --disable-assembly for armv5be.
asm was broken for *any* armeb platform before the changes. Now it's working fine for armv6+, but, ...
- Eliminate use of rev in the armbe code.
... I've been looking at the revs and they now strike me as taking the easy way out anyway. They work around the implicit LE order in which some remaining bytes from a buffer are saved byte-wise. This should be doable without the revs by making the store work in BE fashion in BE mode. I plan to look into this but would certainly appreciate any help Dmitry and Андрей might be able to give here since it's not as if I've been doing nothing but arm asm the last couple of years - rather the opposite.
- 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.
Nah, we can do better than that. :)
I could dust off the old binfmt_misc setup for armv6veb and give that a
That'd be armv7veb, BTW.
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.
No, qemu-armeb should be able to do armv5eb and armv6eb just fine. It's just that I have experience and existing configs for this armv7veb setup since that's what I'm running on my cubies. Once I've sorted that, I should be able to use it to compile to armv5 and armv6 to see what breaks at the compilation stage already. I could also run these armv5 and armv6 binaries through qemu-armeb to see what breaks at runtime. I should also be able to produce similar setups for armv5 and armv6 to uncover any remaining incompatibilities which are somehow masked on the more capable armv7veb setup.
As a ramble, since I wrote it up before re-reading and -interpreting your question: That's exactly what I mean with "cross- and binfmt_misc-qemu-natively-compiling" setup: With Gentoo I can quite easily create a system-integrated cross-compiler toolchain for armeb and the package manager can use it to cross-compile a rootfs containing a native armeb toolchain, nettle and all its dependencies. This can be taken just as far as cross-compiling nettle and then running the testsuite under qemu-armeb, the user emulation mode where qemu-armeb acts as interpreter for the foreign binary executable format via binfmt_misc and emulates the Linux syscalls for the userland programs. It can also go as far as chrooting into the rootfs with qemu-armb executing a whole armeb userland via binfmt_misc and then using the native toolchain installed therein to compile everything including nettle natively (from its point of view).
The latter is what current arm CI is doing IIRC but based on Debian's native support for arm combined with its capability of installing multiple architectures into a single rootfs at once (multillib).
Something similar to the Gentoo-approach should be doable with buildroot which I am currently looking into for armeb CI purposes: buildroot could generate a cross-compiler toolchain and rootfs for nettle CI. This would be much more maintainable than Debian's rebootstrap since armeb is an actual supported target platform of buildroot. A minor problem with it (and likely similar projects such as openwrt) is that they're focused on cross-compilation for an embedded system. So AFAI{K,CT,CS} they are not able to produce a native toolchain for the target platform which rules out qemu variant 2 above.
If anyone knows any other project which produces an armeb binary distribution or specializes in bootstrapping cross-compilers and rootfses that support armeb natively, I'd very much appreciate the pointer.