From nobody Sun Apr 10 00:22:49 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 CD3181A8B5A1 for ; Sun, 10 Apr 2022 00:23:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4KbXks51MTz3N2T for ; Sun, 10 Apr 2022 00:23:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649550173; bh=Jygg+jE7sXg6Wks/ahnLOzunNZLOBXGBfr6LL0cJN2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bkQnm4FllL+g0gUjZ9PIb/KQS6eVcAFHjG2Y9IohtC8nOW036dZ3bcxayFB7lGfIkFH6/zzlP4ICG410eVh+zWIR3BMztlnw1GFtscRwOn3SYvTHgEU4zT2GQQI8uSj/kVbHqcO4bpocJuY9+9hw94eiILWQL4vM+SzNZp6R9C6sPcwMLSRgVmFOIX3sAj2SnQ6d0oa98uXY4YMTuQZsZ0+M0wPcLd4mWiUlCfS36jlihE95WwFJjl2w15078oIE3J0mpHtbeZeLxzQE0LK44F3Q3WIcCHE3J/Clnh3u3JXhxPMYC+Gg29Iq3c2PaZS0c/ms6HPpnOWisOd0hjEbCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649550173; bh=1JAzEyPmidlzXBl4nS5waJHNSarZtoxHXENoGKEsW+G=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y6YGsCVnqmzcNTovFiL3vzpsIJTRwIM/z19QMeZ9Lxe1r3R/55vQ70yuARnA9z/IxdOd0sUYsVFpEDL8hoSVJVenOODxvZaPDssSjhCY8Ia1kNtM4uIYZ7fUkmbiqJlQkFRCSHdqHsQ9r1CeGc0Y94Q5nRENkavZnb1dNoExUoXYtjSfLxIsai3px467R7+a22MuOjP7/9BfTqEh3jKlaMuTp2nF/sBh/HMWqBTG3Rda64Hu9TDCCoVul0tF1JNV3yTdxjtq6cmxEeblT5xf12eTmjQzNCyP3jffuT+c0SzS0zr7Vw/2Ht0tf5I0WOCrcLK/+1IeikDPQx3ZD9HV+g== X-YMail-OSG: 3S42UhoVM1ncoc7ypc2.OkTZufbtrJet8GoImWgbViXizMtcroLswUfEvoLC6jN UkI3ruQ9p5mRY6L7o3OYITLCuupCwy4m8gw646RGLIHW..KSGeqW45ZtfeKHHbk1bR.Z6VwmVRt. Imxo4iBOzAszYiqhcC4Ckew1Vd8_cgp9vobA.wHjBnVD6O8JyffZqCZNu4Ua2rNcYCsIjP99Z5QN j32rGfh.pnkOoWtsp0JSlkTEbUYrqsGWCqdFzI4AMmBp5FiW1r.v0QFfYjZ2CxWi6vz5le5pFCBY c5Wyk_UBMg0uZwWOy1UITkvao0pw_Axlg0r54AGvoGvD28AkWGuJXIYBMW5PqOBovnXSYs4piyQL sXuui1Vs3FseNgUca.dcqMSAXdvYKlmK2ArzE30PLqANSuix2NobBJ9XmvFARTkNflKz3.PiWjzV CTdEaBX32cWUJf0W5LsQBZb8cvv0Fd9fcwap0EyzmSxFz42Od2N28xE5y_V2qD590ElijLlQ5nPP FGdTruVprdz_IqzyeFyHYP9n5XD_K8VffK06jp74tCZetj3xILtt6.dds569uYNHBnLeyzIAmI9A ml5Qg.K7uIXJIVrK0u9ovYSLA_opgspIVEXHAOyEXpAjHfHoGkn5PWiTw.CWOZNPPDQfMYEWPZjY 0CYn8fC6xnFG4eKaLnpfyMQCI20m0yeyLh3ykZTGioFKCwiX7g0dOST3sspEpffpPTrsJWej6XUV .pTPMn2V06EqeuvetlnSKxFZwzO5ciBnqxTyOvW_uTjo1.Xat7W6UUQb.nFIogJ1stO8EP36iVhN MQlF7d3fvhS1cnBnc7CkvbISVWmZL1VncTkGDP_lhBhA9kow9B63RQLqzjXbFaQ6kyaei7VNEvud 1nvUljaxayYSlXf8xduzUKojZGuhkQgISnFD10idEzrXPy.NRCGavKV6xp6TKavjFfNINBNp8a5i Ubu55NJI6qkxQB7t8a0ciTQDtN4zzHwNAlt08Vf6FGm3uTYcL0Yuco_.btBIrHDijwQ0hHLdp4B1 xDZWsBdn82D1I5EWLI8e_LZXwboP1E63XQCGvEYR9xzTE6jc2_2aXQx.wgKEzPpYyPNwczX5wwXf NfADlJXEwSsRgZMWFSDESeeAeaM9Q1644hZcQYPzedw550IC5rRNZyKEA.opyEokdxQZv2LJTojp 5.1aIDAHdp6HASdVapXG1k5vWuSEIXVzI1h9AGtyhCZC6NwXYEpu7agLL40soaQbk6j4JZGkdHvd SwytrHkqKjrkkFSeMG5mLzH1XoV_iFlqQeYa9yUHREefBXVT5GQWtHFTW.QUBAVZ8CqRObXo2S3B XloTowFKRvsuSRBqmFo53W2J4Qq1Fz.Wo9MsMdA9foRvZsDDXfpcD93cX5Qw1k0S1WqSor6d9KW2 QS3y3o_LWvt5hr5emqniUsznyvxjdFl7INl4jszlA8u5dUxZTq34WJb70fnjDQqeAjzXzQqH_sYP n1HRJA2GuCuLoqlyzhat7EvoSr.PYu9omJIHfWtHyLyVIhhyecH0DPefpFLffnWb4JtznUuMT3W. hR72QtJy_eRjYUOZ0.M2WEJxBCPSJb.N7uML6xibzVa9h_Htv7NveKvmymu4yVxUsUBjjLcFE2P3 r2OeHTRbzjtTRpTD9fl_FY2V3fMRbemunLOwZRnwsDmLTscK4kpH19b9jR8uzVUVzoLM.NvYB.hR ZrVCD1oXljVLaebbbBjTt2HSTu79721KzbQFO_AxiXPG_dWkug72IoYzJucTjxxvDz5dMaf.4uDE eKrMLXVXn5kPYtUF_9BAefpsW5tf.AyP40zQ4l_5JG.GFmxGjggarhP6nzV_qmsT3vwbKaPugwCw DdgiuyAhuJYQZ6VSYwB7qs0hH.dJTfWnxOQzOhVHWojBgq3BsH6.IJcgLxKTVK9ztRI_bqRKnIfX Ke1XswHvurFLpnFr9e.q4XQ7oGN4jLY9fE3ewp0c6y6ntiRPz_RpVPNxjga2kUPM81H15B6i2qpv 1rifI_EP0Cn.rpbfo2QRY5qvtJPrcOcYaHnrxmUw2.lzwCX9cHJ91HNi0T1QR5.TI2yu9k8.rmWk dL8cJE9fyA6FH_ZatWDEkoHwx.6KmZNuTy.6un8VmER9BplE9ICul4xADWKT4z14tm32Kxmxq1xm ov7mmY2mJ2GZoZ.N8tuDG7CuayUJYOvPRYImkaM24gDm0xdZUkR63GmWWZ8UdK_ymWWiC2ycrMAj krtp1jboUuioa89MZooOFvSwocB8WPjDQ8Zip8VUF7BWikDp9lbG8Zp1FdWrUV01eXDjMTqgvtBD tqWnfRgJLs5Y9Qa55d8U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 00:22:53 +0000 Received: by kubenode546.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fb0e4346083de05231cb744fd2976cfa; Sun, 10 Apr 2022 00:22:49 +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: <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com> Date: Sat, 9 Apr 2022 17:22:49 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit 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> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KbXks51MTz3N2T X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bkQnm4Fl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 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)[-0.999]; 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.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-9, at 16:54, Mark Millard wrote: > On 2022-Apr-9, at 15:17, bob prohaska wrote: > >> On Sat, Apr 09, 2022 at 01:59:10PM -0700, Mark Millard wrote: >>> On 2022-Apr-9, at 08:44, bob prohaska wrote: >>> >> >>>> Even if one knows which to select and build from ports the >>>> make install command doesn't really install; the admin still >>>> has to know what files to copy where. >>> >>> With good reason for where: the msdosfs file system is not part >>> of FreeBSD's file systems (UFS or ZFS) and there is no standard >>> mount point for the msdosfs in FreeBSD's file system. >>> >> >> I must be missing something here. On the Pi2, Pi3 and Pi4 images >> the msdos partition is always mounted at /boot/msdos with /boot >> part of UFS and the msdos partition under it. Are you referring >> to other platforms? >> > > pkg and such is not limited to RPi* contexts. pkg and such do > not have a bunch of logic based on identifying if it is a RPi* > or . . . or not and doing different things on that basis. What > is it supposed to do for a Rock64, for example? > > But it is not just that which is at issue . . . > > I do not have even one example of an aarch64 FreeBSD installation > that is limited to booting just one type of aarch64 system. The > exact same FreeBSD UFS/ZFS media can be moved between systems > and boot almost any of them: HoneyComb, MACCHIATObin Double Shot, > various RPi4B's, a RPi3B, and a RPi2B v1.2. (The Rock64 would be > in that list if I booted via USB2. But booting it from USB3 is > special, requiring a FreeBSD kernel that is not on the media > plugged into the USB3 port. But with that kernel, U-Boot, and > EFI related material in place on the same media as that extra > kernel copy, again all the USB3 aarch64 UFS/ZFS root file systems > can be booted. The media with the extra kernel is not as portable.) > > So how are pkg or other such to deal with updating such generally > bootable media? 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*? 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)? > 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? > > The early stages of RPi* booting are outside FreeBSD's direct > control and there are a lot of possibilities. > > 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. > > 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. > > 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. > > 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. > > 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? > > 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. === Mark Millard marklmi at yahoo.com