Date: Sun, 29 Mar 2020 02:54:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update Message-ID: <1F506CB0-A809-4DF6-9272-D41239C8A63B@yahoo.com> In-Reply-To: <AB6A78AD-DB89-446E-B150-CA3AC8BE0B67@yahoo.com> References: <B501E3CD-A76E-4D9F-A7AA-70F2D2087BBC@yahoo.com> <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> <AB6A78AD-DB89-446E-B150-CA3AC8BE0B67@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Mar-28, at 19:48, Mark Millard <marklmi at yahoo.com> wrote: > [Just correcting a persistent version number typo: > head -r359376 is correct, not -r359736 . Subject > corrected too.] > > On 2020-Mar-28, at 18:18, Mark Millard <marklmi atyahoo.com> wrote: > >> On 2020-Mar-28, at 17:14, Mark Millard <marklmi at yahoo.com> wrote: >> >>> I use a microsd card that is set up for booting both >>> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 >>> specific materials are in independent places and >>> the rest is shared and rather generic. >>> >>> So at head -r358966 I'd been able to both the >>> Rock64 and the RPi4 from the same media. >>> >>> Now with head -r359736 in place instead: > > Make that: -r358376 . [Not my day. Trying again: -r359376 . But that is not a major point of this note.] >>> A) The Rock64 boots via that media just fine. >>> >>> B) The RPi4 fails to boot (nothing special >>> like "boot -v"). >>> >>> C) The RPi4 with "boot -v" boots just fine. >>> (This makes identifying the issue non-obvious.) >>> >> >> Booting the old kernel seems to consistently >> work (unload, load, boot sequence). Turns our that the following sequence seems to always boot, using just my non-debug head -r359376 build: Get to the boot-loader prompt then: unload load /boot/kernel/kernel boot In other words: reloading the same kernel leads to such boot attempts working. The old kernel need not be involved at all for this kind of sequence. Also: I tried some artifact.freebsd.org debug kernel builds and they all booted fine. (This is not like the OPI+2e boot problem that I've separately reported. The OPI+2e boot-problem has a successful artifact bisection result: head -r359311 breaks things and -r359309 and before boot fine in my testing.) Somehow the RPi4 problem appears to be specific to non-debug builds --or at least to my non-debug builds of -r359376 . >> boot -v of the new kernel can fail. >> >> Plain boot of the new kernel can on occasion >> boot. Such variability likely somehow fits with the unload/load/boot sequence leading to changed behavior. I omit the prior boot-output diffs below. >> . . . === 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?1F506CB0-A809-4DF6-9272-D41239C8A63B>