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:
> 1. 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, ...
> 2. 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.
> 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.
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.
--
Thanks,
Michael
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
