Date: Thu, 11 Mar 2021 21:56:47 -0800 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout Message-ID: <E988FB5E-35E2-4ED0-8393-9D642DE1CEE8@yahoo.com> In-Reply-To: <DBF67DCB-C3DE-495B-B925-3C34DBCF92A9@yahoo.com> References: <YErK5QnSf1SKkcxb@ceres.zyxst.net> <DBF67DCB-C3DE-495B-B925-3C34DBCF92A9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-11, at 21:49, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Mar-11, at 17:59, tech-lists <tech-lists at zyxst.net> wrote: >=20 >> main-n245392-8423f5d4c12 built and installed fine. On reboot it seems >> the microsd card times out. Console log is here: >> = https://cloud.zyxst.net/~john/FreeBSD/main-n245392-8423f5d4c12-no-debug-fa= ilboot.txt >>=20 >> Booting kernel.old works fine. This one is from >> main-n244802-88db1cc9f19 (Feb 14th) >>=20 >> Nothing else has been changed configuration-wise, same msdos = partition, >> same config.txt. Only thing that has changed is /usr/src has been >> updated, built and installed as of main-n245392-8423f5d4c12 (March >> 11th). >>=20 >> Should I raise this in bugzilla? >=20 > Note: I use the official snapshot >=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz >=20 > and its: >=20 > # strings /mnt/boot/kernel/kernel | grep 15565e0a217 > @(#)FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 = 08:02:52 UTC 2021 > FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 08:02:52 = UTC 2021 >=20 > For some comparisons to what you report about your > build. >=20 >=20 >=20 > Some oddities in your report that might need to be > addressed first to make things more comparable > are . . . >=20 > Your log file shows: >=20 > U-Boot 2020.07-rc3-00208-g88bd5b1793-dirty (Jun 06 2020 - 20:33:00 = +0100) >=20 > But = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz > has: >=20 > # strings /mnt/u-boot.bin | grep 2020 > 2020.10 > U-Boot 2020.10 (Mar 11 2021 - 04:30:22 +0000) >=20 > This makes comparison of results messier. You might > want to copy the snapshot file over to your > media. >=20 >=20 > For reference the snapshot for 15565e0a217 > also has: >=20 > # strings /mnt/start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 12:10:40 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >=20 > The Feb 25 2021 start4.elf build is from the officially > tagged 1.20210303 rpi* material from: >=20 > https://github.com/raspberrypi/firmware/tree/1.20210303/boot/ > ( which is what a modern sysutils/rpi-firmware has in > part of /usr/local/share/rpi-firmware/ ) >=20 > Note: many files other than start*.elf are involved but > many do not have such nice, checkable version strings > to look at. >=20 > What vintage/variant was your experiment was based on? >=20 > You might want to copy the snapshot's material over to > your media if your media does not match. >=20 >=20 > Your log file shows: >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > (Thu Sep 17 07:58:43 UTC 2020 root@releng1.nyi.freebsd.org) >=20 > But = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz > has: >=20 > # strings /mnt/EFI/BOOT/bootaa64.efi | egrep '(FreeBSD/|root@)' > FreeBSD/arm64 EFI loader, Revision 1.1 > (Thu Mar 11 07:29:18 UTC 2021 root@releng1.nyi.freebsd.org) >=20 > I do not have sizes or content to compare to see if there > are actual differences. FYI: >=20 > # ls -Tld /mnt/EFI/BOOT/bootaa64.efi=20 > -rwxr-xr-x 1 root wheel 1258796 Mar 10 23:29:52 2021 = /mnt/EFI/BOOT/bootaa64.efi >=20 > You might want to copy the snapshot's material over to > your media if your media does not match. The suggestion might not be the best for EFI/BOOT/bootaa64.efi : Copying your build's /boot/loader.efi to EFI/BOOT/bootaa64.efi would likely be better so it is testing the version from your build instead. > With the deliberate matching of materials, re-running the > experiment and basing any report on the result with a > description of the context would avoid worries about the > mismatches contributing to the behaviorial issues. (I've > no clue if they actually matter or not.) =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?E988FB5E-35E2-4ED0-8393-9D642DE1CEE8>