Date: Tue, 21 Mar 2023 08:14:21 -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: <21A0E9ED-DBA4-409D-BCD2-86E7FCFD2E83@yahoo.com> In-Reply-To: <20230320210353.GZ2347@FreeBSD.org> References: <CANCZdfo7A6%2BzB%2B=Wx5Y9VYFCsSk=Aa%2B9657FxfG0whM-Wsx1kQ@mail.gmail.com> <20230320202847.GW2347@FreeBSD.org> <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> <20230320210353.GZ2347@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 2023, at 14:03, 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: >>=20 >>> 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). >>=20 >> Does chroot and the like count for your purpose? >>=20 >> armv7 packages are built without qemu or the like's >> involvement: >>=20 >> default 131releng-armv7 on ampere3 >> quarterly 131releng-armv7 on ampere1 >> default main-armv7 on ampere2 >>=20 >> This has been going on since 2022-Aug or so. >>=20 >=20 > These are natively built on arm64 hardware. >=20 >> 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.) >>=20 >> Basically all these machines support AArch32 >> in addition to AArch64: >>=20 >> # sysctl kern.supported_archs >> kern.supported_archs: aarch64 armv7 >>=20 >>=20 >>> Particularly, we can only actually use what is >>> listed in kern.supported_archs, >>=20 >> 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 . . .) >>=20 >=20 > aarch64 and armv7 are indeed listed. >=20 >>> at least without falling back to some >>> sort of emulation or wrapper support (such as qemu or the like). >>=20 >> Should not be needed, presuming access to have >> jobs run on one or more ampere* systems. >>=20 >=20 > 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.) >=20 >>> 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. >>=20 >> 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 >>=20 >> sysutils/u-boot-*: Remove ubldr support >>=20 >> 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 >>=20 >>=20 >> So: before 2021-Jun. >>=20 >=20 > Noted. Thank you for looking. >=20 >>> 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. >>=20 >>=20 >=20 I do not know why it took me so long to think of it, but artifacts.ci.freebsd..org already has examples of *.txz files ( base-dbg.txz base.txz doc.txz kernel-dbg.txz kernel.txz tests.txz MANIFEST ), such as seen at: = https://artifact.ci.freebsd.org/snapshot/main/daa0b64a226031d5f753f96cd5a6= fb3234cdd8b1/arm/armv7/ = https://artifact.ci.freebsd.org/snapshot/14.0-CURRENT/daa0b64a226031d5f753= f96cd5a6fb3234cdd8b1/arm/armv7/ = https://artifact.ci.freebsd.org/snapshot/stable-13/854424168f8e939894aa5fc= ffeec5201c4265542/arm/armv7/ = https://artifact.ci.freebsd.org/snapshot/13.2-STABLE/854424168f8e939894aa5= fcffeec5201c4265542/arm/armv7/ = https://artifact.ci.freebsd.org/snapshot/stable-12/7812b9ef0dc15118a4df783= 36982cfb67d59f49a/arm/armv7/ = https://artifact.ci.freebsd.org/snapshot/12.3-STABLE/7812b9ef0dc15118a4df7= 8336982cfb67d59f49a/arm/armv7/ So there is a known, exmaple way to produce such files for armv7 , at least ones sufficient for artifacts.ci.freebsd.org . =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?21A0E9ED-DBA4-409D-BCD2-86E7FCFD2E83>