Re: earmv4 packages coming soon
David Brownlee <[email protected]> Sat, 14 May 2022 19:13:15 +0100
| Newsgroups | gmane.os.netbsd.ports.hpcarm,gmane.os.netbsd.ports.arm |
|---|---|
| Message-ID | <CAGN_6pZnL82b0S5DUHcHPjpYzMu4ZZg9Q-gsfymLzQk16SD60w@mail.gmail.com> |
On Sat, 14 May 2022 at 15:55, John Klos <[email protected]> wrote: > > Hi, all, > > I've never been quite sure about the differences between earm (earmv5) and > earmv4, but since earmv5 packages won't run on earmv4, I've started a bulk > build of earmv4 packages. > > Which makes me wonder: is there any downside to running earmv4 packages on > earmv5? Does earmv5 make use of features that significantly improve > performance over the same earmv4 code? > > If there is no significant improvement to running earmv5 specific > packages, then I might just build earmv4 instead. > > Also, not that this matters much, but build.sh with -m evbarm -a earmv4 > doesn't work, although -m shark does (and I'm sure -m hpcarm and friends > work, too). IIRC it was StrongARM (v4) vs XScale (v5), I think there were a fair number of Thumb additions... but I think the main difference is v5 added VFPv2 which is handy for floating point. evbarm already has an ld.so.conf: libc.so.12 machdep.fpu_present 1:libc_vfp.so.0,libc.so.12 I wonder if it makes sense to have some form of libc_vfp2 to allow v5t CPUs to run a v4 build without (most of the) floating point penalty... David Now... I don't know if it's possible to build an armv4 userland with an optional libm