From nobody Mon Mar 20 21:23:08 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PgSQJ1nWTz40HYs for ; Mon, 20 Mar 2023 21:23:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PgSQJ1JmVz3rBm for ; Mon, 20 Mar 2023 21:23:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id x3so52190562edb.10 for ; Mon, 20 Mar 2023 14:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1679347399; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=krGsrHy52kGjYd3npJM9b93BYuOaI2+x8TfhGrmorFU=; b=mQi1m8/SsQwN3wBmM4KBPevGfU7znXFKeyK+f3gX9OJNv78wdUtl/En1PyRfkS1v3+ rPaq4K49Ka1scqcaIdKtqH5ZW/nxPW23jPSV3I4usGwzrM2uCGWyUljGkvJQewrIM6CF EfBBvkaLBCvTyCoGowNWYXFYQ/fsQHbB6vb//zZgX/+tK9rR02g0B7kWPK+c/j/hehcZ vjyYOcWxZDH2+VeM6dMQKuHmCzEJzaTKNBavn0Tk2MPjnY9g6UqsQFi3eDm5ljYlhypV wajHfvY352We3nfocf604Z4VeH4+cDdA4QL97XW6iEMNnT7fZY0sH8iyCiibcHTDRQzR k3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679347399; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=krGsrHy52kGjYd3npJM9b93BYuOaI2+x8TfhGrmorFU=; b=etjBpjGbK7iFYS7FT76tcHeg7kziBHiEs4b5Sghgp7fTC8W1blpCfG04p0R014hurg 8t7bn0eTzYc9x8j/Xpr1BUnAKV1mH/J9mSD6FelRwLSb6Kchl/kyPdKLtfW4TwsGdRVq N5cYUO0UrEaduj1o1ONEcpE/0B7pdP50MI6F4Nl3O89KRKWqnCppIPGvcdaD+gPADyJD KkSW7JFfgma5d8oCn5Ng+7GPgSkvqvsAdIWJVyG2uBZ/6OZVxKr8o39P7pd0uxj+RKaU SKRQjxWC+ihXsO+9O8PxrYHJkAF9IeAucaz9kL7Zg6+9o7FUO8ljH9UjfOj+i+abo4kl uPrQ== X-Gm-Message-State: AO0yUKVsyVU+l7l2CK6scndaBpExR+QCtrSJ2tqwzZcA42Vum9D4lwrj y4h5LbBzsIOdLGjtFbYhixmI/OB0KDafA6zzfYlGsA== X-Google-Smtp-Source: AK7set/BzOZGI010l8Cu/Tk8cZ5d5Vp4mHULZIrW63SDzKdJjvwSRD6PqZBNZZ5X6jPOmTOq1JOxwdbLgK04F1GXC1E= X-Received: by 2002:a17:906:c413:b0:92f:7c42:863d with SMTP id u19-20020a170906c41300b0092f7c42863dmr246878ejz.2.1679347399082; Mon, 20 Mar 2023 14:23:19 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <20230320202847.GW2347@FreeBSD.org> <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> In-Reply-To: <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> From: Warner Losh Date: Mon, 20 Mar 2023 15:23:08 -0600 Message-ID: Subject: Re: Poudriere friendly armv7 relases To: Mark Millard Cc: Glen Barber , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000002d559505f75b8952" X-Rspamd-Queue-Id: 4PgSQJ1JmVz3rBm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --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 wr= ote: > On Mar 20, 2023, at 13:28, Glen Barber 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 2021-05-11 18:27:14 +0000 > committer Emmanuel Vadot 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


=
On Mon, Mar 20, 2023 at 2:51=E2=80=AF= PM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
O= n 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 F= reeBSD 14
>> (armv6 has been nominated for deprecation, but if it isn't dep= recated, 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 buildi= ng from
>> source.
>>
>> Is there some reason we're not doing this today? I know ISOs d= on't make a
>> lot of sense in the arm ecosystem, but having these artifacts woul= d enable
>> poudriere binary install support.
>>
>> Comments?
>>
>
> Several.=C2=A0 :)
>
> 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<= br> > that it was not 1:1 compatible with how base.txz, etc., are generated<= br> > for other architectures.
>
> 1) For other architectures, base.txz is result of the 'ftp' ta= rget in
>=C2=A0 =C2=A0/usr/src/release.
>
> 2) armv7 does not have an 'ftp' target.=C2=A0 (Well, it does n= ot *disallow*
>=C2=A0 =C2=A0it, and probably should at the immediate moment, but it do= es blow
>=C2=A0 =C2=A0up.)
>
> 3) Most importantly, and the reason I stopped looking further into thi= s,
>=C2=A0 =C2=A0we cannot run native armv7 binaries on an amd64 system (at= least,
>=C2=A0 =C2=A0last I was aware).

Does chroot and the like count for your purpose?

armv7 packages are built without qemu or the like's
involvement:

default=C2=A0 =C2=A0131releng-armv7 on ampere3
quarterly 131releng-armv7 on ampere1
default=C2=A0 =C2=A0main-armv7=C2=A0 =C2=A0 =C2=A0 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.)

<= div>True, but I want bsd-user's armv7 working and upstreamed... it will= make doing riscv64, which
doesn't have this, easier to suppo= rt next.
=C2=A0
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
>=C2=A0 =C2=A0listed 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
>=C2=A0 =C2=A0sort of emulation or wrapper support (such as qemu or the = like).

Should=C2=A0 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 instea= d
> of hooking into release/Makefile, having a base.txz did not make much<= br> > 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.=C2=A0 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. 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. END QUOTE


So: before 2021-Jun.

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 :)

Warner
=C2=A0
> 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 sur= e
> 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--