Date: Mon, 20 Mar 2023 15:23:08 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: Glen Barber <gjb@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Poudriere friendly armv7 relases Message-ID: <CANCZdfqHx_D=q-c99zzmDY6cJpTV1%2BArq_gbS0ithqtZw=gU2Q@mail.gmail.com> In-Reply-To: <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> References: <CANCZdfo7A6%2BzB%2B=Wx5Y9VYFCsSk=Aa%2B9657FxfG0whM-Wsx1kQ@mail.gmail.com> <20230320202847.GW2347@FreeBSD.org> <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000002d559505f75b8952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2023 at 2:51=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wr= ote: > 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 1= 4 > >> (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 armv= 7. > >> 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 mak= e > 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. > > 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.) > True, but I want bsd-user's armv7 working and upstreamed... it will make doing riscv64, which doesn't have this, easier to support next. > 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 thi= s > > 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 suppor= t > 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. > Yes.. but there's still some customers that use it.... and I'm saying that they are niche enough at this point to not care :) Warner > > 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 > > --0000000000002d559505f75b8952 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 2:51=E2=80=AF= PM Mark Millard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O= n Mar 20, 2023, at 13:28, Glen Barber <<a href=3D"mailto:gjb@freebsd.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 F= reeBSD 14<br> >> (armv6 has been nominated for deprecation, but if it isn't dep= recated, all<br> >> this applies to it).<br> >> <br> >> I'd like to start making at least the base.tgz, etc available = for armv7.<br> >> This would allow us to create armv7 poduriere jails without buildi= ng from<br> >> source.<br> >> <br> >> Is there some reason we're not doing this today? I know ISOs d= on't make a<br> >> lot of sense in the arm ecosystem, but having these artifacts woul= d 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 some<b= r> > environment knobs to the way armv7 is built, however I later realized<= br> > that it was not 1:1 compatible with how base.txz, etc., are generated<= br> > for other architectures.<br> > <br> > 1) For other architectures, base.txz is result of the 'ftp' ta= rget in<br> >=C2=A0 =C2=A0/usr/src/release.<br> > <br> > 2) armv7 does not have an 'ftp' target.=C2=A0 (Well, it does n= ot *disallow*<br> >=C2=A0 =C2=A0it, and probably should at the immediate moment, but it do= es blow<br> >=C2=A0 =C2=A0up.)<br> > <br> > 3) Most importantly, and the reason I stopped looking further into thi= s,<br> >=C2=A0 =C2=A0we cannot run native armv7 binaries on an amd64 system (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> 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></blockquote><div><br></div><= div>True, but I want bsd-user's armv7 working and upstreamed... it will= make doing riscv64, which</div><div>doesn't have this, easier to suppo= rt next.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex"> 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> > 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> > Back when armv6 and armv7 support was added using shell scripts instea= d<br> > of hooking into release/Makefile, having a base.txz did not make much<= br> > sense because there were different environment variables that were<br> > passed into the resulting output, some of which affected the loader<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 +0000<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 support = for booting with ubldr and the needed patches that were never upstreamed. W= hile here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy in the Fragment as it= 9;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></blockquote><div><br></div><div>Yes.. but there= 9;s still some customers that use it.... and I'm saying that they are n= iche enough at this point to not care :)</div><div><br></div><div>Warner</d= iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > That said, I can take a look and see if we can package base.txz for<br= > > armv7, however I would like to do some archaeology work here to be sur= e<br> > that the resultant output is not going to have unexpected behavior<br> > because of the userland not matching 100% the target SoC.<br> <br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> </blockquote></div></div> --0000000000002d559505f75b8952--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqHx_D=q-c99zzmDY6cJpTV1%2BArq_gbS0ithqtZw=gU2Q>