Re: Poudriere friendly armv7 relases

Glen Barber <[email protected]> Mon, 20 Mar 2023 21:03:53 +0000
Newsgroups	gmane.os.freebsd.devel.arm
Message-ID	<[email protected]>
On Mon, Mar 20, 2023 at 01:51:27PM -0700, Mark Millard wrote:
> On Mar 20, 2023, at 13:28, Glen Barber <[email protected]> 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 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 <[email protected]> 2021-05-11 18:27:14 +0000
> committer Emmanuel Vadot <[email protected]> 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
signature.asc (application/pgp-signature, 833 B)