Date: Wed, 30 Dec 2020 12:00:23 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <0160302A-B566-4B9E-A9BB-48BFC1043FD4@yahoo.com> In-Reply-To: <20201230183052.GA56823@www.zefox.net> References: <CB0E5ECD-CDDA-46A7-812B-744AF7645A78@yahoo.com> <20201229010220.GA36311@www.zefox.net> <78A4DEC3-421F-419D-ABDE-9F3724E44C8D@yahoo.com> <7E0A320A-4C81-4C7B-B5D0-E6681FFA24FC@yahoo.com> <DB6C87A3-19DC-4979-AC17-FD1261782803@yahoo.com> <67E8786A-79E7-409A-BF4D-738F4FEB5EFF@yahoo.com> <20201229235701.GA49529@www.zefox.net> <D562F29B-7154-49DC-B1FC-1ACA20695897@yahoo.com> <20201230035447.GA50440@www.zefox.net> <CC9C9212-6F7B-429C-8846-E0FF1333E388@yahoo.com> <20201230183052.GA56823@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Dec-30, at 10:30, bob prohaska <fbsd at www.zefox.net> wrote: > On Tue, Dec 29, 2020 at 10:49:09PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2020-Dec-29, at 19:54, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>> On Tue, Dec 29, 2020 at 05:28:55PM -0800, Mark Millard wrote: >>>>=20 >>>>=20 >>>> On 2020-Dec-29, at 15:57, bob prohaska <fbsd at www.zefox.net> = wrote: >>>>=20 >>>>> On Tue, Dec 29, 2020 at 02:50:07PM -0800, Mark Millard wrote: >>>>>> . . . >> . . . >> As things are, you are out of the bounds that FreeBSD currently = supports >> when you try to build stable/12 on an armv7 FreeBSD 13 (or armv6 = FreeBSD >> 13) with the built-in toolchain (counting stable/12's Makefile*'s). = (The >> same likely applies to 32-bit powerpc.) >>=20 >=20 > It's worse than that: I'm trying to turn back time. I wanted to test = the > stable-12 upgrade path for armv7 and used the 13-current box because = it was=20 > handy and expected backward compatibility. Makes no sense in the = context > of an OS. It makes more sense to wait for stable/13 to emerge and test = that, > given that 13-current seems to work with armv7. The handbook warns = against > crossing major versions, doing it in reverse compounds the trouble, = since > developers have no reason to expect anybody in their right mind = _wanting_ > to do it.=20 The official armv7 builds are done via creating a 12.2 release jail that does the 12.2-STABLE build --on a machine that may have been booted via a more recent OS version. (I'm not sure what butler7.nyii.freebsd.org is booted with.) In fact it is also a cross build running on 64-bit = hardware, not running on armv7 hardware, not that such is essential. (I looked at: = https://ci.freebsd.org/job/FreeBSD-stable-12-armv7-build/lastBuild/console= Text .) A somewhat analogous chroot context could be used on the RPi2. You could get materials from: https://artifact.ci.freebsd.org/snapshot/12.2-STABLE/r368787/arm/armv7/ base.txz possibly: src.txz possibly: ports.txz possibly: base-dbg.txz and expand the tar(s) into an initially empty directory tree. chroot to that directory tree. mergemaster or such may be needed. Have 12.2-STABLE build itself in that chroot context. Install from the build to some media the RPi2 can use for booting (update or from scratch). Use the media in the RPi2 v1.1 to boot 12.2-STABLE . (You may want to provide a different source tree than is in src.txz . You might want to mount_null a source tree into the chroot area before doing the chroot.) There are details I've not covered, like having /dev ( and /dev/null ) show up in the chroot area. I referenced an artifact.ci.freebsd.org snapshot because neither of: http://ftp3.freebsd.org/pub/FreeBSD/releases/arm/armv7/ nor: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm/armv7/ has such armv7 .txz files available. (arm64 does have such in the analogous places.) >> . . . >> That the armv7 (/armv6) always has a "small" address space is a = hardware >> issue (instruction set architecture), not software. That -O1 (and = clang >> 11's -O) requires more than 2 GiByte per-process spaces to build >> clang.full is the consequence of (mostly) LLVM choices. FreeBSD = chooses >> to be LLVM based and FreeBSD 13 chooses to be LLVM 11 based (until = LLVM >> 12?). >>=20 >=20 > Given the continued "expansion" of LLVM, it seems likely that before = long > it will become incompatible with armv7, despite the use of = optimization.=20 > Does this seem correct? I've not checked how big of a user process is involved in linking clang.full when -O2 is in use. I do not know how much room that there is for more in that kind of context. >> . . . >=20 > That seems pointless as I now understand the situation. Nobody has > a practical incentive to compile old OS versions with newer ones.=20 > I tried it only out of laziness. The official technique is less direct than what you were trying, in that it uses a 12.2-RELEASE jail to build a 12.2-STABLE . This avoids issues like -O in clang 11 not matching -O in clang 10, even if the host machine was booted with 13-CURRENT. Something similar can be done with a 12.2-STABLE armv7 snapshot from artifact.ci.freebsd.org . That would stay in the supported range of activities/relationships when used on the RPi2 v1.1 booted with 13-CURRENT. > When the arm64 Pi3 came out it seemed likely that FreeBSD's support > for 32 bit arm would erode. As LLVM gets larger the erosion can only > speed up, particularly for self-hosting. I wonder when armv7 will be > "too small". I do not know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0160302A-B566-4B9E-A9BB-48BFC1043FD4>