From nobody Sun Apr 10 08:02:15 2022 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 036C51A874E0 for ; Sun, 10 Apr 2022 08:02:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kbkwz4GTMz3QGq for ; Sun, 10 Apr 2022 08:02:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649577739; bh=P/AaVWI6mTAxKLzDPxYvxgMo5zp1v/gI3jQJTFyvyN8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=V3rSoNMj9KWf+juU055IPYegFCu9F4bdw0hlaPQf/SY5PQ48uC2Kp1qJO8jfo1fDDVxudnGg4L9Oqxt4e//0qkH2AyzyL2bJdBAaw3soIDEDo+XBwos366AgDuDWFenE8LVqjf4DatdacwxLzhAHdsg0swkuSnnnhjO7jP5zS5nXu6HRm2G+wtDbUifSa4vSmvlyr+0CWjtmWBAqq0dr4wfGuxjFILCU4v50xU6f267moDUwF0taHY/R88YQXMuKYIksDSP2H8nQJR4lflTPXv+L4ROG1nV9XzXIS8vzPyHNRhmqhOqkLg/kro8NBDcWgataxUhFkclx26RWoX/9dg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649577739; bh=IR9l2N6gymTE58jb42k2ezXfq+B6S227AoNvYYnQkLC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IqLkycdQwdFqdNarErD21Po2u9RduBthuIXRPujRgV8H2Gd5+b1LFVavWR4noR0FiFc8u7YpGgbPEYwypoN6FPGiLjwzUxZNd0HMizltPrU6fsyuHWAd3MM8Ji935yBL2cciVO2B9ltsLgQOwY/cklktDJOWyQTu6evHXiZS2lk38Yu2omg/7U3cvkx3E+oRYlFi0GaabUNYyIsmauSN0i6EbFxTm9pLW2fG3/cVluSmY6zVjuBh2HgxBygophxeFvDmxTpXfbLHgkUsCj18tndnac8RUy+1Z2Rb+0vphy1F1sC2wbIqFbF2MaCSxvJYQ/EDx+/ML2Nm7H9LG04jTQ== X-YMail-OSG: 9YrGSVEVM1mEAtqkVlkIBTRZKwdyWoAWfbseXVJ7Z6zh48ELdFyF5RhMfB5S0rW KWnEI_K2QFIDsUQqYgyZMBeygAmLUZLgaxyOIgHCOG06RWvnJcWBJVKggXOfY35WdDjDqD0_CLe1 THJGsxXf6eal8bFWN02snHe4aUWaptW56IqlW7b75taIeNf5VjRaZVQOF4C6JR7kxc_rahkPk7ld uir81asonR.0UGgoQhBQSwjVfwP763b_LI.vDXhOaQz6p6dm5rvhvyZ8e1eza4NdjGypLm_OPyPD mSEfMovvNVGZ8rDWrZKZBCjofCxBAmAkUf2AChWBpf1X4asKhejX5GQwfB.Ji_NlutMsxnin5iky zssqp6UBER4G7emmBcrcUAYjvWuPYyVd3ITiMPsqGqaHoF8Qgwwrk2os5IBwiCfIqNHalQsaRHVC HR5SFCe_aEFl7nwSUy.a.iwf9qgs7wMGhNH5tIlXB6EA5e5vSCKXFpKMlk_8nAx0RExkwyTJX.wi ZSNMrHC5Hv3FuncZwNLo9echQMApW98SkVtoXNJxOh5QbbSjIOsdzku9xMWH._JFrPWe4G60hLMz yLdQ5JhW.d4yxMSIHotPDe_IvOgEw_K4in38q2f4w2gpNWNPLo1XnfGIHlBbA3tsFWQtYv6qtloV Zo6gbwKoqCUg2Ocv430EkN8gtDqqDRsMoJe5xs4fWHUTvZKohbqzYqrHHHmL6Y9xzQNNtRJkOOWT O3hmkjWqcTiyfgY2NEHpO5BJcW72.TCs0RVP.9QmENWlssw4632edExhaSTM7SJ0b5UG46Cd.T9a rUlenaIsRpL_MoYotH0Q8KmnIrvn_XRwccpEWuM6BsXXTHg_orboXWRdYTJcmcn80oZn0KWAQbkp Ap0CCdHEJNWvdgS61Kutr51n17EIE6595OFc8mvSVNfTjTs.LFKmdhkmHKG7SkxUjnwXRgTv0BIP K1ayyJuLKx9mIbzAxsexYb6upglOzhMCtWrgLVepfr4ER.j6j4wgHpWRYhK49CAE20BKlaqPCCKl UG_NlDCNZpPupH7lII3Sc1vi1hkoaACeXY3FdpGxCDeC1ujXEtH1LXiA0DbGEg2n17V0wFSTrAce WwvBj5pN8aHEGVm9r25bK8neIy3MPNxVdGtyP.ewCFp1MoJkJqlm.SvVcM3Zs.mdDh9OKYjD8IfD ewRzjSBJAcjksQcYEsODW3ZFSERo_6zTL8H_EYCFtG9TrCPKjQJNGQ5KguuCmpM6mE7HBNgvyzN7 GMvjIsdXplbREyRSXdjdQ24HyACLkgg.l..VvoiLi_78TB_qc1Zg7tP1YnLoApG7z7xSRSv6A1nM 3KojJ8iP1BOOgN3IaxjIHEHViYx_be7zeeW_j42xBiFqYrVvWNZIkJFxk_wzoQGKiVfdMaBh2UkM z.5.aJRNnLhM6gyHY7xVUwu94eu_xFAqE8sFiBZeV7PLk3qIADIVk17tUdsTT34igu8HAMEpjLSe fF8h6cK8ZxbCA7zTr8vgHtyguK.Zp75heMTDzJscuA31ntRUY9e6XmBnLs.LHJ0DhVaYKgm8vEVi KqsH9_mOx6ZxQGOZFfBwgxBWKffA0yfhyBKkPntjmOpiV1HWvtX19i4Z.HnUlxjLyuXruZuunc.Y nWi2zZ2sZDoJHojgXDimGdm.ZSX5om6zCXjEw_HxkzqWCCZLnElfoQgdlMHiN2JbzWbTFNduyQSN p5Zea3Nru6GkDOa5XazpMrVO7N4E9Ofu7riFXyv6HB6Wx9El6qMxefhYIn8UWUjDS.51OhwSR.qA lz0Myy31AUStPldWLv_erGLTzoh7Co8Xg0MI5kmrILwuBIP4XkP4_hhy2rBrZu4a_Syk3zp3umBT lQeWGYU4oBq_ZAlqL__ySynvgBIJ.Vdz5t7nfJltIETPIRjlfCtlpvRo125yGW6hAioru2iihimE lCKSZHkaEvfOhNxUXjAtNUbtIN7zNNLbnwKnPj8IEZupGteAt1r3hT7PYVpGLzlvN7FBtDlsAydK JAwDzYq32NyfZCRwTb7qgGFt2D64XOEmEhnHOExnvTV7XwbpM3jHCf1miYOld1BqKfIhnVAkWIxT JIERzN59dEsEQp2BC8W.RI4wX6wQzFtKeHuQm64RbonxE0FXCu2aAYy6xtfGRoIYBgdfs3WViWJc Vz4mvm.FPM2QcQv38FLjMaRNAx63mebYgDqVIEf9f5b6mflIx11kewp_V3imOW.eRsJowenhoRdZ 66jOLOSxbDvy3TUEjWCue_ErK19PdDZXrv2WMzw4uaHo6A_HFY9FeOwdIIxbuPiBDvbK73sdmICX PPtJBE0_PRa_sbut9DaE2lcilNQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 08:02:19 +0000 Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID 95a9ce7d87da96805bcca8f79ea72e7f; Sun, 10 Apr 2022 08:02:17 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with -current From: Mark Millard In-Reply-To: <20220410033906.GA57250@www.zefox.net> Date: Sun, 10 Apr 2022 01:02:15 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220409015321.GA52002@www.zefox.net> <20220409154433.GB55458@www.zefox.net> <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com> <20220409221742.GB56550@www.zefox.net> <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com> <20220410033906.GA57250@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kbkwz4GTMz3QGq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=V3rSoNMj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.204:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.204:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10006 Lines: 265 On 2022-Apr-9, at 20:39, bob prohaska wrote: > On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote: >>=20 >>> So how are pkg or other such to deal with updating such generally >>> bootable media? >=20 > I don't think they can be expected to update alien media. What alien media? Depending on how you have things set up for /etc/fstab use, likely your no-microsd-card-required USB3 RPi4B media would boot the same list of machines that I indicated. ( I use labels to avoid numbering variations and reference the labels in /etc/fstab .) > There are lots of platform-specific ports for u-boot. Why not match > the install target to the named platform? And how does one do that? > If folks go to the trouble > of creating a port for a platform it's little extra work to add the > pathnames. Most Small Board Computers do not have file path names for U-Boot materials: They are put outside the file systems on the media. There is a "seek" position on the media. RPi*'s are fairly rare for putting such in a file system at all. For example, for the Rock64 the instructions for its U-Boot and related material are: QUOTE To install this bootloader on an sdcard just do: dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync END QUOTE The dd commands are very dangerous when done inappropriately. "sdcarddevice" is only suggestive, since other types of devices are possible. In fact, the Rock64 I use boots via an e.MMC device that the board supports, not the microsd card slot. That is true even if a microsd card is in the slot at boot. As I remember, there is a jumper on the board for controlling which of the two is used by default. Lots of Small Board Computers have multiple devices that can hold the U-Boot involved, with some means of control over which is used. > What you're talking about seems far more ambitious. Seems you are viewing what you want to happen as trivially easy to make happen. >> I should have explicitly noted: How likely is that that I'd happen >> to always do FreeBSD updates on a aarch64 RPi* instead of one of >> the other systems, especially the faster ones? Is pkg to notice and >> update RPi* boot materials because the updated system could also >> boot an aarch64 RPi*? >>=20 >=20 > Presumably you'd cross compile a package for the intended target and > then install the package on the running target. All the machines I listed were aarch64: What cross compile? Your wording presumes that the target boots fine already. What about setting up the first boot ever for the target --or recovering from boot failures? > The platform details=20 > would be part of the package. Which boot media is in use for the RPi* firmware and U-Boot stage is not a fixed property of RPi* platform: it can be used various ways via configuring it differently. > If the target is RPi3 and you're compiling=20 > on Cavium, the RPi3 paths would be part of the package. The Cavium > won't be running the pkg install, As stands "pkg install" means putting the directory tree with the instructions and files under the likes of /usr/local/share/u-boot/ . You are creating a distinct operation and reuse of the terminology makes things are to talk about/follow. But if a Cavium has USB ports or microsd card ports supported by FreeBSD, it certainly could be used to create the matching type of media for a RPi4B, including getting RPi* firmware and U-Boot in place, as well as EFI and UFS/ZFS material (same or different media). For the machines I listed in an earlier part of the exchange, they all can produce USB drives usable in booting all of the others --and I take great advantage of that. The two machines with PCIe slots can produce PCIe media used in booting that work in both. The Rock64 can produce microsd card boot-media for any of the machines. And so it goes. > but I don't think that's possible > in any case. Both pkg and make install work on the host they're = running=20 > on, no? =20 The assumption that things need to be run on the target system would be false. That is only one way of working when multiple systems are available for use. >> This better illustrates what I'm referring to when I reference pkg >> and the like identifying contexts and handling a variety of them. >> Should it be checking if it happens to be running on a RPi* and >> behave differently than it would on other types of systems (same >> boot media)? >>=20 > That's the admin's discretion. He knows what the target architecture > is and the media being written. So it can not be automatic and the admin must do the work to set up something that matches the context --at least that sounds like what you are saying. >>> Or: Say that the RPi* has a msdosfs on its USB device that is >>> able to be used for booting. But that, at the time, there is >>> also a microsd card present that capable of being used for >>> booting, at least for the RPi* firmware and u-boot.bin stages. >>> What sort of activity is pkg supposed to do to identify the >>> context? How would pkg even identify, say, which way FreeBSD >>> had been booted? >>>=20 >=20 > I'd suggest this is an unrealistic scenario. Pkg can know what > files it's supposed to update, the admin has to make those files > accessible. If the wrong paths are mounted, that's a wetware problem. So, here the admin must know/remember where things need to be and set up the mounts, it is not automatic. >>> The early stages of RPi* booting are outside FreeBSD's direct >>> control and there are a lot of possibilities. >>>=20 >=20 > Yes, too many. The admin has to constrain them. Admin? FreeBSD? If the procedures are part of FreeBSD instead of being created by the Admin, it is not the Admin that is placing the constraints. >>> Nothing in FreeBSD says that /boot/msdos should exist or be the >>> mount point used as far as I know. It is just something that the >>> snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently, >>> do by the free choice of the author(s) involved. >>>=20 >=20 > But it does exist and is useful. Why not use it? Most Small Board Computers do not have U-Boot in any file system: no way to mount anything to /boot/msdos that would help with the typical dd commands for U-Boot (and related material). It only works for the files that go in a msdosfs. (RPi*'s are unusual for this.) So any such convention is of limited utility across the range of Small Board Computers. >>> In fact, if you tried to use bsdinstall to set up a RPi* >>> context, it would not set up something like the >>> snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I >>> know. >>>=20 >=20 > Can it work at all? As I remember, it can set up a EFI file system with FreeBSD's loader in it. The other files would have to be copied over (presuming the same media was the desired target for them). > I always prefered the installer whose man > page said it was "greaty in need of death".=20 >=20 >>> Nothing says that RPi*'s have to be set up the same as the >>> snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential >>> differences in question are not part of FreeBSD. >>>=20 >=20 > But in practice they are, and it's useful for most folks. >=20 >>> Another common convention is /boot/efi (especially when the >>> msdosfs invovled has the FreeBSD efi boot loader as well). >>> FreeBSD does now have some predefined behavior for this >>> convention. >>>=20 >=20 > Curiously, my Pi4 has an empty /boot/efi, but I've never > tampered with it. >=20 >>> What if nothing is mounted to /boot/msdos or to /boot/efi >>> at the time (say, disabled in /etc/fstab)? How much analysis >>> of the context is pkg or such to do and adjust for? >>>=20 >=20 > Just report "path not found" and list what was expected. >=20 >>> The FreeBSD loader.efi has the same sort of "there is no >>> fixed place for it" issue. Other than the /boot/efi use, >>> there is no automatic update of loader.efi either. This is >>> largely because the copy used to boot is not in a FreeBSD >>> UFS/ZFS file system at all --but in some msdosfs file >>> system, possibly with a special partition type. >>=20 >=20 > My plea is not for adaptability, but acceptance of convention.=20 The convention does not work for most types of Small Board Computer U-Boot (and related) placements: Most use dd to someplace outside all file systems. RPi*'s are unusual in that they have u-boot.bin as a file in a file system. For example, /boot/msdosfs as a mount point does no good for U-Boot (or its related file) for a Rock64. Basically, you are asking for special handling of RPi*'s, at least relative to U-Boot. > Identify a platform and a location Normally: not a file system location at all for U-Boot. > then put that info in the > port install target. Let convention be set by the image.=20 >=20 Again: It is rare that a type of Small Board Computer has its U-Boot in any file system location. The assumption that most things are like RPi*'s is false based on what I've seen. For example (from README's of 4 u-boot ports for devices I use or have used): dd = if=3D$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl= .bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img = of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb = of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync dd = if=3D$LOCALBASE/share/u-boot/u-boot-sinovoip-bpi-m3/u-boot-sunxi-with-spl.= bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync dd if=3D/usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin = of=3D/path/to/sdcarddevice bs=3D128k seek=3D1 conv=3Dsync /boot/msdosfs mount point conventions do no good for any of those specific commands. =3D=3D=3D Mark Millard marklmi at yahoo.com