Re: Poudriere friendly armv7 relases

On Mon, Mar 20, 2023 at 3:03 PM Glen Barber <gjb@freebsd.org> wrote:

> On Mon, Mar 20, 2023 at 01:51:27PM -0700, Mark Millard wrote:
> > On Mar 20, 2023, at 13:28, Glen Barber <gjb@freebsd.org> wrote:
> >
> > > 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).
> >
> > Does chroot and the like count for your purpose?
> >
> > armv7 packages are built without qemu or the like's
> > involvement:
> >
> > default   131releng-armv7 on ampere3
> > quarterly 131releng-armv7 on ampere1
> > default   main-armv7      on ampere2
> >
> > This has been going on since 2022-Aug or so.
> >
>
> These are natively built on arm64 hardware.
>

I should have pointed out that my requested change is useful for this as
well.
Independent of my desire to have it for cross builds, is the need for this
setup
to be installed w/o building from source.

Warner


> > I personally build for armv7 on a HoneyComb
> > and have done so on a RPi4B in the past. (This
> > is both system builds and package builds.)
> >
> > Basically all these machines support AArch32
> > in addition to AArch64:
> >
> > # sysctl kern.supported_archs
> > kern.supported_archs: aarch64 armv7
> >
> >
> > > Particularly, we can only actually use what is
> > >   listed in kern.supported_archs,
> >
> > The ampere*'s should list armv7 in addition to aach64.
> > (I've no access of my own to directly validate but
> > given that ports are turned into packages . . .)
> >
>
> aarch64 and armv7 are indeed listed.
>
> > > at least without falling back to some
> > >   sort of emulation or wrapper support (such as qemu or the like).
> >
> > Should  not be needed, presuming access to have
> > jobs run on one or more ampere* systems.
> >
>
> The release build machines are (by design) kept separate from the rest
> of the infrastructure within which we operate.  (Same for the package
> builders, as well.)
>
> > > 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.
> >
> > QUOTE
> > author Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 18:27:14 +0000
> > committer Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 20:22:54 +0000
> > commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch)
> > tree a22f954f3003c1361f4ea5a411e92759a80c9089 /sysutils/u-boot-master
> > parent c5fd1c2e186abb2e3209fa48d75d8dcdcda63f06 (diff)
> > download ports-0d6e5081eb0080c4703f1c5cc69c34f38d9149b7.tar.gz
> > ports-0d6e5081eb0080c4703f1c5cc69c34f38d9149b7.zip
> >
> > sysutils/u-boot-*: Remove ubldr support
> >
> > We have been using loader.efi on armv7 for a long time now. Remove
> support for booting with ubldr and the needed patches that were never
> upstreamed. While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=y in the
> Fragment as it's needed to have the cache flushed for us when loader.efi is
> started.
> > END QUOTE
> >
> >
> > So: before 2021-Jun.
> >
>
> Noted.  Thank you for looking.
>
> > > 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
>
>