Date: Tue, 17 Mar 2020 23:42:09 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Upgrading u-boot on an rpi3 Message-ID: <4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787@yahoo.com> In-Reply-To: <20200318054243.GA67865@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On 2020-Mar-17, at 22:42, bob prohaska <fbsd at www.zefox.net> wrote: > Upgrading u-boot on an rpi3 running -current is turning out to be > more involved than expected. Updating /boot/msdos/u-boot.bin didn't > do the trick, getting stuck at the u-boot> prompt. > > Backing out the change by putting the old u-boot.bin in place > restored the normal boot behavior, so I don't think the mischief > is owed to anything else I might have screwed up. > > I noticed there was a metadata file in /usr/local/share/u-boot/u-boot-rpi3, > but copying that along with the new u-boot.bin to /boot/msdos > reproduced the previous failure. The metadata file is involved in doing the build. Some look like: METHOD=uboot-raw FILES="u-boot-sunxi-with-spl.bin" OFFSET=8 BS=1k (dd command information) and others like: METHOD=uboot-file FILES="u-boot.bin" (copy file to msdosfs information). They are not for the ARM board to use during boot. > This is a self-hosting machine, with ports at 528581, > kernel and world are at 351836. Sources are at 358976 > > Could the self-hosting be the source of the trouble? > The "no mmc device at slot 0" looks rather odd, given > that the boot device is mmcsd0. u-boot's identification of devices is not the same as FreeBSD's. "MMC Device 0" need not be "mmcsd0" at all. Slots do not have to be populated an mmc device. > Here's an excerpt from the console: > > Hit any key to stop autoboot: 0 > MMC Device 0 not found > no mmc device at slot 0 > switch to partitions #0, OK > mmc1 is current device > Scanning mmc 1:1... > Found EFI removable media binary efi/boot/bootaa64.efi Those last 2 lines above indicate that it found your microsd card media and its bootaa64.efi just fine. How old is this file? Have you been updating it via copying /boot/loader.efi to it as /boot/loader.efi is updated? I've had issues needing such updates when starting from old media [by content] that I made a large jump to modern content for. For reference, the RPi4 said "scanning mmc 0:1" and found its bootaa64.efi there. But it is a difference device so this would not be unusual. > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disk mmc@7e300000.blk... > Found 3 disks > BootOrder not defined > EFI boot manager: Cannot load any image > 637000 bytes read in 63 ms (9.6 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Consoles: EFI console The above looks normal compared to the RPi4 that I tested with. The below is not like the RPi4 test. > efipart_readwrite: rw=1, blk=0 size=1 status=2 > efipart_readwrite: rw=1, blk=64 size=1 status=2 > efipart_readwrite: rw=1, blk=1 size=1 status=2 > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > efipart_readwrite: rw=1, blk=0 size=1 status=2 > efipart_readwrite: rw=1, blk=64 size=1 status=2 > efipart_readwrite: rw=1, blk=1 size=1 status=2 > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 Back to normal below: > FreeBSD/arm64 EFI loader, Revision 1.1 > > Command line arguments: loader.efi > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8217.4096) > Console: efi (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) > Setting currdev to disk0p1: Still normal above. Not normal below: > efipart_readwrite: rw=1, blk=0 size=1 status=2 > efipart_readwrite: rw=1, blk=64 size=1 status=2 > efipart_readwrite: rw=1, blk=1 size=1 status=2 > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 > efipart_readwrite: rw=1, blk=0 size=1 status=2 > efipart_readwrite: rw=1, blk=64 size=1 status=2 > efipart_readwrite: rw=1, blk=1 size=1 status=2 > efipart_readwrite: rw=1, blk=250085376 size=1 status=2 Back to normal below: > Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x197c7,0xee66839) > Setting currdev to disk0p2: Not normal below: > efipart_readwrite: rw=1, blk=0 size=1 status=2 The only messages that look odd to me are the "efipart_readwrite:" ones. For reference from the RPi4 context: . . . Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B4CF1DF-F3C0-4ED3-AAC0-4FC0A8182787>