From nobody Sun Apr 10 18:35:09 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 574D31A84538 for ; Sun, 10 Apr 2022 18:35:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4Kc0zF5ptZz4kHN for ; Sun, 10 Apr 2022 18:35:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649615713; bh=f1MXOZPND37NL0a71O0PghAhkn7YYE/EfPQ0cjPWW+w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iaK6/ivjyxy366Hq6plwGatQ3YUD//lNaX1oyaNdiSrKpgz+QgAYVXROpZfAyVHWJygP9HTYHNBmozMnddDbOnTt/ZTtENV2Xop3JM9WIYKEha0gyeAAHvJYvKgd7Cv5ZH7AGch+AJ51rL7PQV6zZFzeTzo8XC6qR9OGs9SxLCgS/tC+288m9BbjKCBJ7DSg2CxLdt0Fuxt0tFAk3lFGy7mNCXnNBnLKK37XlUgWE1BkimdZE3HoluqlczdkMnMdhitloMqmTRng1Hx6S6WTEg8XiPormh91g1tbupbW+AcRDBgjvysKyOY5LGPZra1vtq5mNxerI9zEjM8MU9IY+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649615713; bh=wecW+MRMX6t1zRML9QCWmMJ2wdIW+nPI/8+hEdorOux=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fluAV0eQrRrBa/nHkqCojBlTGtmV7cFo6LSzYbT+qBwQWVpLSWn9ow4Iekf6fAthvRNqUoQ5M3LI3Zx0bYm6GTCcOKhWVcFhdSkKyuenmTRQLMQfOz23Mcvxz+8jYExJhqnc1uEiN1mk2Hv4831wyk0bXVa/EGAg0gNhKaTiBjLkOdcwPokzeCtJLL+PdXc3Nv2rXN+y9uxnJWn6GD1x7rrtGo39RblVqabCYFtL1xfOznC+5PGkp6PfqVI4jJi73jFJk+kvdXMdBOXZ97kcmjjLUSn2/7k7sv0WJTKIduNMcjdYQbRCReVztBeNe3do+S1UzRGRINCUT/zdSmYBZw== X-YMail-OSG: N_29Q30VM1kusrXcpKZGXUxKly9Sj.dnvGaVPwEMGsYq84b.jSypc1AxgSv1QM2 2pO2yOqhkOul6bAWg2bCJJAzgsM8wTeNplbZ9D_fkJIrGdCFZ_FNyGGE8D8FnXN7nhGWtAJ_BOG8 SdAQDSZcDIc0AHtTp8mVoZckFwW0A0NKQKw4cHwiHFXpnfW.X.MdA4.Re5sSyPBeRlb7RlG8Glx0 E9BiNhRlbMoZxs6eGdfuNddqLUNdo6vwQe._cmhbJ1guZro.Qt1hXaMopCkdRoqyR.pmCVh80N.s Ftqcv.WHiswTjkSq5Q.6JkfQN5NeGer1vwDptdqYh7vAVVetF5dBAgEForaoISAnwE0Es9.5qpdb NUatvGX7az2CghT3i5Jw6vKuez1guGkzmY_JOVUJLqauLhgDDrpf2oV9jkHPi0hp8r5ZTWymZ0St _hxU_555NahoYXWhSCVZEoy55.Quum1ZgM31ZhjhxXG2swipvZwlNnKOzq4AdNKIHAONhvGlJTRQ YWaPvyjhlPaINf8LhFdFG1gt6b5A91Dcp0GFC8BDZoIkebStHJAHEoToudOuVtzOODVzGN5xNnlb wiCIAeUOOU6He3kL3ZjVEpeCxvPvSd2LBmnKOOK1L.0opnggfDtS5qJMHx9oBZEUrVuJ1vzkPzBt zRIFurCFm_PdsHOX6RA8586u.ovvSQy._mTPqa9arx7lODgcifC3.q1R5nXJNLGlVeEHbV6m2dVP eaDuSsTXpmS0bPcN3_fnLfVviz2YyS0BZfFNAjWsEZ_9MyH9POT_EUxDNNcpZB3sUFxwriRDOE_Z EuJbXqYKGsPbNlF_QzqRn1WBKpZpsJSrKNsK9jg1pIhkj1Ua3OHxKkMap2QT6fq5MDQLp1OPV9n7 xY_CaeJk3A4qKuyqDRqmknrqq6KkIjcIYUrZTS0Ga.rMrv3In3dpEJybwuUdK37dxPwGS3dNZyjN QFGhYalQ7.wk9jHQDLjdW71SA0CdMXl7lm7okhdocQRpFYKtwMfKiw43_NK2sx1wqVZILoE3Ax9J dwmTQKbWw4dmfXmxyIl.DrOiyFz70YOItKh54uu.2US_ahrCCTXmZ6Xhbpz47KRT.Kk3VlbkcZdF D9JjsUP_hOkxZgoerjU_v5ZSpdo11Y1XECzQ5Uv_v2agTKbeAUoZYGQ376pMdwHRCHDYgYVF9b2S LRiO44q6oyJ9W1WSEkNhIGs9K9ePzlCoNTCmbdKJr64WWzPfYV0NykCTEJUd4yZkApR.dzUJ546H BOe6a4AQGplVIfUYZP47kccL4fmcE.Uk7MmBOVIHlOgIe59Zb9qCVhepNbqWh9p39D078tJrEoyD 8zgAu1vXTNJHs4.U5ILxaqgLOiXxC48YGQg5VwgV.X4AvGIaMwkrE8xgCeHMkZ13UalZFWoCylze VKeGoj1wD3oYgmFkeHBHmzB2eyk_cQoe52lZxeQV5iSYuINP4Hp9_sFtUaNk5d5KTBVQQEFZ3Zrz fDAhfxkWvRmSPDnzFSnkM75hGUsEZT56MVvQ3x.uKtd6plv91SFW6dTt.Oh80d9XUefPkxnfqdQA BT1pyYKrVoSdVxtWBElMWPuRIwBzAuLqNor2xDqYI1g6oH29NrAU5HsPVTLfA3bxHZiQ.5XrZWDz F3oz0fttndUhpRiXfjr3zXxTfxAjRa..j.ex.wB1uBbn_vM8uHH9PqgF9vZHfAW6Rxe33SkCtcew DgrzkonOCA9h6Qyj91lZfZtwawRGwIRELRTKtqPHIJ5gJxM3T7__.1juUlTaZuny4WEFWP8MQB2w D.jvnRA8GVtPIGZC0aHAQ7h5SWG1VWhg8MQYrhh2ay4yJz0.WUx1838kDnMzs1FRSflLu3db.Kob lE4_C_n4KrbfrSW7iI7SZOkp5tYeppxDIXBdmdCi.eCYgho.jBDBbjaLehDmMC53YasxENJCivKJ AwzilH7Y0mAMfVoapvz4zkfmVekb6Sy0qluM4r93sWMTBO04ALsjYnREowuQn7KqQLKbRXtNxw8m KQdgsRZwSudBSaJqntc3IouxWZ91VLvYPK2MwWCN4d5JxCizrE8h5E0wSFDKTCNU9eKI6drPGnpM Go5OiCnmYXsl.RM0mTCbVHEo0rm_pWnjCfHQlacSf5lz6RK2cnHAoD94plQ2GNRnnQ.gwqbdgTbD er1p.qo0JszjkbV5smVBKWkBK7Z3drfDZR49UDyyppsPGYiLLbfiWW3mnN6nfMl4kJaHa7JypoXh k24fW4nORGpcMx7vfTQj8ZuOeKuWS_i1tLp03V6hquqm0j4GT2egifqhxDMpqO7.Gj4LiNbrWSah pfFG6J9Mx6Jjs X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 18:35:13 +0000 Received: by kubenode520.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4db1eb8961b7557807c3a6fe0e441a30; Sun, 10 Apr 2022 18:35:09 +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: Date: Sun, 10 Apr 2022 11:35:09 -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: 4Kc0zF5ptZz4kHN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="iaK6/ivj"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 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)[-0.999]; 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.65.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [Just fixing a really bad typing mistake.] On 2022-Apr-10, at 01:02, Mark Millard wrote: > On 2022-Apr-9, at 20:39, bob prohaska wrote: >=20 >> 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. >=20 > 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 .) >=20 >> There are lots of platform-specific ports for u-boot. Why not match >> the install target to the named platform? >=20 > And how does one do that? >=20 >> If folks go to the trouble >> of creating a port for a platform it's little extra work to add the >> pathnames. >=20 > 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. >=20 > For example, for the Rock64 the instructions for its U-Boot > and related material are: >=20 > 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 >=20 > The dd commands are very dangerous when done inappropriately. >=20 > "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. >=20 > Lots of Small Board Computers have multiple devices that can > hold the U-Boot involved, with some means of control over > which is used. >=20 >> What you're talking about seems far more ambitious. >=20 > Seems you are viewing what you want to happen as > trivially easy to make happen. >=20 >>> 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. >=20 > All the machines I listed were aarch64: What cross compile? >=20 > 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? >=20 >> The platform details=20 >> would be part of the package. >=20 > 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. >=20 >> 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, >=20 > 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. "makes things hard 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). >=20 > 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. >=20 >> 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 >=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. >=20 >>> 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. >=20 > 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. >=20 >>>> 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. >=20 > So, here the admin must know/remember where things need to be > and set up the mounts, it is not automatic. >=20 >>>> 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. >=20 > 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. >=20 >>>> 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? >=20 > 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.) >=20 > So any such convention is of limited utility across the > range of Small Board Computers. >=20 >>>> 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? >=20 > 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). >=20 >> 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 >=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. >=20 > Basically, you are asking for special handling of RPi*'s, > at least relative to U-Boot. >=20 >> Identify a platform and a location >=20 > Normally: not a file system location at all for U-Boot. >=20 >> then put that info in the >> port install target. Let convention be set by the image.=20 >>=20 >=20 > Again: It is rare that a type of Small Board Computer has its > U-Boot in any file system location. >=20 > 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): >=20 > 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 >=20 > 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 >=20 > 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 >=20 > 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 >=20 > /boot/msdosfs mount point conventions do no good for any of those > specific commands. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com