Re: Poudriere friendly armv7 relases

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:
>> 
>>> 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 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 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=y 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 sure
>>> that the resultant output is not going to have unexpected behavior
>>> because of the userland not matching 100% the target SoC.
>> 
>> 
> 

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/daa0b64a226031d5f753f96cd5a6fb3234cdd8b1/arm/armv7/
https://artifact.ci.freebsd.org/snapshot/14.0-CURRENT/daa0b64a226031d5f753f96cd5a6fb3234cdd8b1/arm/armv7/

https://artifact.ci.freebsd.org/snapshot/stable-13/854424168f8e939894aa5fcffeec5201c4265542/arm/armv7/
https://artifact.ci.freebsd.org/snapshot/13.2-STABLE/854424168f8e939894aa5fcffeec5201c4265542/arm/armv7/

https://artifact.ci.freebsd.org/snapshot/stable-12/7812b9ef0dc15118a4df78336982cfb67d59f49a/arm/armv7/
https://artifact.ci.freebsd.org/snapshot/12.3-STABLE/7812b9ef0dc15118a4df78336982cfb67d59f49a/arm/armv7/

So there is a known, exmaple way to produce such files for armv7 ,
at least ones sufficient for artifacts.ci.freebsd.org .


===
Mark Millard
marklmi at yahoo.com