Date: Mon, 20 Mar 2023 13:51:27 -0700 From: Mark Millard <marklmi@yahoo.com> To: Glen Barber <gjb@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Poudriere friendly armv7 relases Message-ID: <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> In-Reply-To: <20230320202847.GW2347@FreeBSD.org> References: <CANCZdfo7A6%2BzB%2B=Wx5Y9VYFCsSk=Aa%2B9657FxfG0whM-Wsx1kQ@mail.gmail.com> <20230320202847.GW2347@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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, >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> Comments? >>=20 >=20 > Several. :) >=20 > 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. >=20 > 1) For other architectures, base.txz is result of the 'ftp' target in > /usr/src/release. >=20 > 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.) >=20 > 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. 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 . . .) > 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. > 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=3Dy in the = Fragment as it's needed to have the cache flushed for us when loader.efi = is started.=20 END QUOTE So: before 2021-Jun. > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477846FC-FC56-4A2E-B2BD-FB98500B0F7F>