Re: Poudriere friendly armv7 relases

On Mon, Mar 20, 2023 at 02:06:50PM -0600, Warner Losh wrote:
> Greetings,
> 
> Since it looks like we're going to retain at least armv7 for FreeBSD 14
> (armv6 has been nominated for deprecation, but if it isn't deprecated, all
> this applies to it).
> 
> I'd like to start making at least the base.tgz, etc available for armv7.
> This would allow us to create armv7 poduriere jails without building from
> source.
> 
> Is there some reason we're not doing this today? I know ISOs don't make a
> lot of sense in the arm ecosystem, but having these artifacts would enable
> poudriere binary install support.
> 
> Comments?
> 

Several.  :)

I have looked into this in the past, and mhorne@ had even added some
environment knobs to the way armv7 is built, however I later realized
that it was not 1:1 compatible with how base.txz, etc., are generated
for other architectures.

1) For other architectures, base.txz is result of the 'ftp' target in
   /usr/src/release.

2) armv7 does not have an 'ftp' target.  (Well, it does not *disallow*
   it, and probably should at the immediate moment, but it does blow
   up.)

3) Most importantly, and the reason I stopped looking further into this,
   we cannot run native armv7 binaries on an amd64 system (at least,
   last I was aware).  Particularly, we can only actually use what is
   listed in kern.supported_archs, at least without falling back to some
   sort of emulation or wrapper support (such as qemu or the like).

Back when armv6 and armv7 support was added using shell scripts instead
of hooking into release/Makefile, having a base.txz did not make much
sense because there were different environment variables that were
passed into the resulting output, some of which affected the loader
output, etc., specifically with regard to u-boot.  I am not sure if this
is still an issue or a concern, however.

That said, I can take a look and see if we can package base.txz for
armv7, however I would like to do some archaeology work here to be sure
that the resultant output is not going to have unexpected behavior
because of the userland not matching 100% the target SoC.

Glen