Date: Mon, 20 Mar 2023 15:24:36 -0600 From: Warner Losh <imp@bsdimp.com> To: Glen Barber <gjb@freebsd.org> Cc: Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Poudriere friendly armv7 relases Message-ID: <CANCZdfoycbmdBHUJK58=Jx7OfWCpa7MJH%2Bk9xRF-J4n=575swg@mail.gmail.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
--0000000000006e129005f75b8efb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2023 at 3:03=E2=80=AFPM 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 inste= ad > > > 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. > > 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 su= re > > > that the resultant output is not going to have unexpected behavior > > > because of the userland not matching 100% the target SoC. > > > > > > Glen > > --0000000000006e129005f75b8efb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 20, 2023 at 3:03=E2=80=AF= PM Glen Barber <<a href=3D"mailto:gjb@freebsd.org">gjb@freebsd.org</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon= , Mar 20, 2023 at 01:51:27PM -0700, Mark Millard wrote:<br> > On Mar 20, 2023, at 13:28, Glen Barber <<a href=3D"mailto:gjb@freeb= sd.org" target=3D"_blank">gjb@freebsd.org</a>> wrote:<br> > <br> > > On Mon, Mar 20, 2023 at 02:06:50PM -0600, Warner Losh wrote:<br> > >> Greetings,<br> > >> <br> > >> Since it looks like we're going to retain at least armv7 = for FreeBSD 14<br> > >> (armv6 has been nominated for deprecation, but if it isn'= t deprecated, all<br> > >> this applies to it).<br> > >> <br> > >> I'd like to start making at least the base.tgz, etc avail= able for armv7.<br> > >> This would allow us to create armv7 poduriere jails without b= uilding from<br> > >> source.<br> > >> <br> > >> Is there some reason we're not doing this today? I know I= SOs don't make a<br> > >> lot of sense in the arm ecosystem, but having these artifacts= would enable<br> > >> poudriere binary install support.<br> > >> <br> > >> Comments?<br> > >> <br> > > <br> > > Several.=C2=A0 :)<br> > > <br> > > I have looked into this in the past, and mhorne@ had even added s= ome<br> > > environment knobs to the way armv7 is built, however I later real= ized<br> > > that it was not 1:1 compatible with how base.txz, etc., are gener= ated<br> > > for other architectures.<br> > > <br> > > 1) For other architectures, base.txz is result of the 'ftp= 9; target in<br> > >=C2=A0 =C2=A0/usr/src/release.<br> > > <br> > > 2) armv7 does not have an 'ftp' target.=C2=A0 (Well, it d= oes not *disallow*<br> > >=C2=A0 =C2=A0it, and probably should at the immediate moment, but = it does blow<br> > >=C2=A0 =C2=A0up.)<br> > > <br> > > 3) Most importantly, and the reason I stopped looking further int= o this,<br> > >=C2=A0 =C2=A0we cannot run native armv7 binaries on an amd64 syste= m (at least,<br> > >=C2=A0 =C2=A0last I was aware).<br> > <br> > Does chroot and the like count for your purpose?<br> > <br> > armv7 packages are built without qemu or the like's<br> > involvement:<br> > <br> > default=C2=A0 =C2=A0131releng-armv7 on ampere3<br> > quarterly 131releng-armv7 on ampere1<br> > default=C2=A0 =C2=A0main-armv7=C2=A0 =C2=A0 =C2=A0 on ampere2<br> > <br> > This has been going on since 2022-Aug or so.<br> > <br> <br> These are natively built on arm64 hardware.<br></blockquote><div><br></div>= <div>I should have pointed out that my requested change is useful for this = as well.</div><div>Independent of my desire to have it for cross builds, is= the need for this setup</div><div>to be installed w/o building from source= .</div><div><br></div><div>Warner</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> > I personally build for armv7 on a HoneyComb<br> > and have done so on a RPi4B in the past. (This<br> > is both system builds and package builds.)<br> > <br> > Basically all these machines support AArch32<br> > in addition to AArch64:<br> > <br> > # sysctl kern.supported_archs<br> > kern.supported_archs: aarch64 armv7<br> > <br> > <br> > > Particularly, we can only actually use what is<br> > >=C2=A0 =C2=A0listed in kern.supported_archs,<br> > <br> > The ampere*'s should list armv7 in addition to aach64.<br> > (I've no access of my own to directly validate but<br> > given that ports are turned into packages . . .)<br> > <br> <br> aarch64 and armv7 are indeed listed.<br> <br> > > at least without falling back to some<br> > >=C2=A0 =C2=A0sort of emulation or wrapper support (such as qemu or= the like).<br> > <br> > Should=C2=A0 not be needed, presuming access to have<br> > jobs run on one or more ampere* systems.<br> > <br> <br> The release build machines are (by design) kept separate from the rest<br> of the infrastructure within which we operate.=C2=A0 (Same for the package<= br> builders, as well.)<br> <br> > > Back when armv6 and armv7 support was added using shell scripts i= nstead<br> > > of hooking into release/Makefile, having a base.txz did not make = much<br> > > sense because there were different environment variables that wer= e<br> > > passed into the resulting output, some of which affected the load= er<br> > > output, etc., specifically with regard to u-boot.=C2=A0 I am not = sure if this<br> > > is still an issue or a concern, however.<br> > <br> > QUOTE<br> > author Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 18:27:14 +00= 00<br> > committer Emmanuel Vadot <manu@FreeBSD.org> 2021-05-11 20:22:54 = +0000<br> > commit 0d6e5081eb0080c4703f1c5cc69c34f38d9149b7 (patch)<br> > tree a22f954f3003c1361f4ea5a411e92759a80c9089 /sysutils/u-boot-master<= br> > parent c5fd1c2e186abb2e3209fa48d75d8dcdcda63f06 (diff)<br> > download ports-0d6e5081eb0080c4703f1c5cc69c34f38d9149b7.tar.gz<br> > ports-0d6e5081eb0080c4703f1c5cc69c34f38d9149b7.zip<br> > <br> > sysutils/u-boot-*: Remove ubldr support<br> > <br> > We have been using loader.efi on armv7 for a long time now. Remove sup= port for booting with ubldr and the needed patches that were never upstream= ed. 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= . <br> > END QUOTE<br> > <br> > <br> > So: before 2021-Jun.<br> > <br> <br> Noted.=C2=A0 Thank you for looking.<br> <br> > > That said, I can take a look and see if we can package base.txz f= or<br> > > armv7, however I would like to do some archaeology work here to b= e sure<br> > > that the resultant output is not going to have unexpected behavio= r<br> > > because of the userland not matching 100% the target SoC.<br> > <br> > <br> <br> Glen<br> <br> </blockquote></div></div> --0000000000006e129005f75b8efb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoycbmdBHUJK58=Jx7OfWCpa7MJH%2Bk9xRF-J4n=575swg>