From nobody Tue Mar 21 15:14:21 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 4PgwBQ0rwjz40Qfc for ; Tue, 21 Mar 2023 15:14:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PgwBP4XtBz3PvD for ; Tue, 21 Mar 2023 15:14:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679411675; bh=sMFE3Zsv/k52rUZGHtXaU1lT3X4o7yQ9e2xRIYrhWbU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BtU4ngxr/h9TRoLUjQmL6d3jj0zBpeEo9rmBPgOAUMJrOkvvy5zUo3VTLwCI/Ow1bDLJtmdzr61Fp3ocmYzEPQc6MKpknEYU3ZOLtVFuk8sJIj1lTVeDqOADvA7KA7nUzDVHcDdU+s+uV5ODxApDzUcZMCBHa2colIyVx534HrH081W/nzZy5ZWRMw2IBELo1oHA5pyQ9sCqSHshkzc3Mwx8nlR5poCLpaNxSPaGHrwzIBFJ/W3beetswlN0CPvpQgwLmQyCgIf3vLy6G9gSXC8kSWqsoyTvYxKCDlPFcxy1too5GWOAvmAncl/lfihcLAy0xPAZ0X1ygwotoZen1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1679411675; bh=1KJBm6b53Refnc5ZrmRWtYUDRCRt5oBsvhcA1YeOWib=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nPBGOw1xiSc3CVM9TVfooQWFwE2Rw7kSa5JzpwDQqOj6fRUcfe8toPORe1cWKWWFdxUcl1CCrVngQ1FOyXY0o16ffrd98gayVwKtDeuznXRXZYOxgOl3FL06wogk7uuDZIB8DpDNPUdu9mB4wmO7YErPmSMKcyno8EkigKew7FDg3WGQ/eJqOuZooksHVfTMQywPR15ETngOm9aPaho2S//mwC4O2UA+4v0UW+HhRu8X/mY9Rl3RkDUvv/oPVNxKsaCJT42beUQAolH8OloJNP91BHipyFUugkTEyLBsLLdBRSLVC6efP0Yhaw9vi5TZow9bN+Zh6+ZeE2AQJ52CUw== X-YMail-OSG: gSBunvMVM1nWngT7PXB9Yix63dPzYYA7R1Fggfn07S8PMutGHcuBrjvJS6hHeIs 668C.obLjkDwi7DLbcXA0xN7FYiSFLkrNhlR.X0K18L34TLmQtYZGN9nK.0.oVUfN8Q6YNxdbsb0 l_A0.NBjcTlbOE0ErGjoLV4MNypxUb8e6WoTmLBup56YxBJaxJ7i6VnCarDjwUmso89VDzLIkMbY .womwPx_pPw8L.vaOaNeYyL6VJRCOhfAWecSgyt6mfKtzQZqcNEatqtbtTwI.XLx2Ltyq8.dHlr. FW0jn9efN7IUFpe7cxg1IsViJdqaEKUClw2L_wSBoMUpmKW000kVgCnbOKdjjHzDFF9aiDqbi70z XQZZvBOLnW_.n20aYzYr5nN7crgFpFGW90rbkhvSadGQYu.OKtitgc2QBni2K.wdy6xPUxAc0dh3 PYWvnjIEg8MJGzLACLbfuufIKKx2KxID_QOXqFG7FGS03ONyirC9v13FrEWHWAbGYfhG2ElNmIlY PaVvuUIFjZMsVCaX2IK.bJg.vp4gGaSrKNDgiS7e0ZfX2WupEVeaKoubssC6q0bDDEGk672R4U6h uRmezRlaFbxkcKd_zNt3vpA1Ei.Mwk.OQnkY7MnsPqtR9JedjFyYv3ym9gp7aNKDYh3oSO2D52mr tCLz2J2HLuOKFTEMMwBOHRmuCL0bklrVJziZ2cGX4k_f3p_cpKH88FfpyUwi1ueGmTOY83xLY2nx 0yWDG_sTsVyeweh4fZ4s1zQ07XZrzWYafd47iF7lJ9n3XRQ_6n83vcS5Q7YIoHVi2tyEHTT3hwAO C38zl1S.UQJgc5NYqctBFTkbqzFEuwRwc2dKfcRQv6glrEWDVhA6qi2v9DntuwBzcogekn.ns6Ps LtDwXWnbZO4TVmUOsgGuFYHs62XnGATekwdhunsLIUSIKgJyojsEdVoTsliTry.3YFt7EFAXC_EZ YbXPEXCPkT0nOw6y0_qH5B.fX9SR.GJdjN3SH8iUpKTB3gfUETRbpSkgf8JMwbGvkQYkKR.Fzx5j V9CGB9kJD2y35CnHWbb.PX8WC8JY9qs.swiM6TrafX.qW.uYrJb60SHhwar_XwME_YL8Lh91XT0_ wBZOo_4Iuu99lhHjfFHTHNCg.jMHfNFiV4wvtg97X8sLOA6X60p4RYDhIuXBapHxetf4lKxJ2_F9 DcgLqZjqpH7h0XGPq_oI3hjXoxyLm3CW8ouF.fUweH.JQgX2bYzEQAKti3IBaYtYTaSFYXo4sMeX p7U8tuU_l8FfM_VmeeiY.zrYF1q8Vscfnxo076g_UbfyO9l2TEhvqrmD1fpNHkRHBq03tRfCSCf_ 8apBo6itaTD0v7OmXhBoujsWr1yloG7oRUzip8muU3brEfrS.YWOucyExck2qnRwXWKmCp_pqOs3 B27kW_MVgkjudRPRw1RV36YBjbhrnb8O0O3JEeMo7ouKOEPXLIAiNZs5cm_32JfIAIL1pXsRlbdA Znp9AOGIHifWDRvXnsZZC9HIbTE1zhMG679c5SJ11N4ff7dqeQuWpjTekg0FhEhrlWleSiMjOIeX w5ADoRL70WMOEWFVGa5PsNcBbL4I0.JdD_lrpe3oJWB4ZJSckOcKpNVAzl9Ui3qwATZ_Ah5sdwWM rUjeRqZUWeRWXNK.FKhV9nV_4EZyGLarwtjFQSPCx4zbAmaHv4heb1CZA23_BMW6QLp5_lWkqNRC 9TWO70.cN7aE_iMu6iz0IFt.YmTGGpHOTLZdVSrXQm1OPUwxrVtAC6sD6G6iTLrWZrJtkZSai9ow si8mld9DjVS0TNNktTSv.Lngx4vIj368r3RSugPgYU74Aqz.EaB5yOYP3jRGzCf_EM9Rl.xexxS4 XlfnLttIt2YsWKNRsPhdM2IFhHnd9w7kAgNdKykALr9Ye6E296.e4wvxh7GPkuXw5OGHLnG0lqPl eROhkWusk40sTWSqPA8XvNxMpHf1Ucr2J_uzZ_nNDB_RbT7On5sY6YhlhThTsPSJeeSBVZhnKTY5 gAGqZdC6sTkK_cWcxDsPU66F7I_hib5bL0i9zVK7WLg2UeKpNelU.miF0KIGZJOfNqQKIrA29Ni6 7shQeOnpprzx6JpG4ZiDpO71IFsCzY5yEmTVF8lAEs9.zkZ0w5TBrSV_0sJR19b9GLNJ_q6SyXfb osPTV3ulWe2.26OhIBS_Xmsu6XugzCLkuhJC4OcOyGfJJCYNNwDHMX6V8AipYJQcetuF6qenTLY5 Uyt.1IKdPxzql.MH2eb1CVuRqiUusicBP3wSjMXQGGbcBUXsWRm5A12quWC5AvjeotzWyxauanbq KUg-- X-Sonic-MF: X-Sonic-ID: 1b34c3ec-a683-422f-bf5a-de880c5edb6c Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Mar 2023 15:14:35 +0000 Received: by hermes--production-ne1-759c9b8c64-z75s7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 134c1a88c1446311bd66a77df38c3543; Tue, 21 Mar 2023 15:14:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Poudriere friendly armv7 relases From: Mark Millard In-Reply-To: <20230320210353.GZ2347@FreeBSD.org> Date: Tue, 21 Mar 2023 08:14:21 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21A0E9ED-DBA4-409D-BCD2-86E7FCFD2E83@yahoo.com> References: <20230320202847.GW2347@FreeBSD.org> <477846FC-FC56-4A2E-B2BD-FB98500B0F7F@yahoo.com> <20230320210353.GZ2347@FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PgwBP4XtBz3PvD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mar 20, 2023, at 14:03, Glen Barber wrote: > On Mon, Mar 20, 2023 at 01:51:27PM -0700, Mark Millard wrote: >> On Mar 20, 2023, at 13:28, Glen Barber 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 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 >>=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