author | state | changed |
---|---|---|
M Warner Losh <[email protected]> |
draft |
2017-06-09T16:20+0000 |
A new MACHINE_ARCH for the armv7 machines is needed. While one can support armv6 and armv7 in one architecture, it creates a lot of unnecessary friction.
While it initially felt like similar to the difference between i486 and i586, the number of changes required to make this happen are larger, especially in ports. Linux has agressively adopted armv7 as its processor name. In addition, being able to optimize differently between armv6 and armv7 will help enable or disable newer programs like lld.
- Change the build infrastructure to accept armv7 as a valid target.
- Change the build infrastructure to generate code optimized for armv7 target.
- Change the build infrastructure to have the same speical cases for armv7 that we have for armv6.
- Have all the kernels, except RPI-B, use armv7 as the target arch, so uname -p returns the right name.
- Rename RPI-B to GENERICv6 since it is the only board that's supported with an armv6 SoC.
- armv7 and armv6 binaries look pretty close to the same, so we'll need some way to not run armv7 binaries on an armv6 kernels.
- All ports that have tried to shoe-horn in the current infrasture need to be examined and likely modified.
- Ports exp run will need to be run for both armv6 and the new armv7
- Package infrastructure will need to grow armv7 support
- Need to change places where we document the lists of valid architectures.
- build(7) and arch(7) need to be updated to reflect armv7.
- src.conf(5) needs to be regenerated with armv7 in the list
- cloudabi(4) needs to add armv7 to the list of supported architectures
- We'll need to migrate the armv6 stuff to armv7.
- Add new arch. Normally this is a hassle, but it's movement in this case, not additions.
Currently, many things are based on the machine processor being armv6. Those would need to be audited and change. There will be customer visible downstream changes needed.
We'll need some way to support upgrades on either side of the integration into the tree.
We'll need some way to upgrade armv6 packages to armv7.
Linux uses armv7l or armv7b for this. NetBSD uses earmv7hf and earmv7hfbe. Regardless of what we do, we can't leverage either of these names to make ports easier. And since neither matches FreeBSD's other architectures, or historic practice on the arm, we've decided to go forward with 'armv7' and will use 'armv7be' if necessary.