Upgrading u-boot on an rpi3
bob prohaska
fbsd at www.zefox.net
Wed Mar 18 17:23:23 UTC 2020
On Tue, Mar 17, 2020 at 11:42:09PM -0700, Mark Millard wrote:
>
>
> 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:
The reference to dd is rather confusing in this context. Has it
something to do with cross compiling on to new bootable media?
If dd is required in self-hosting then I'm doing things very wrong.
>
> 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?
Rather ancient:
-rwxr-xr-x 1 root wheel 637000 Oct 10 2018 /boot/msdos/EFI/BOOT/bootaa64.efi
I have a newer version on a 12.x snapshot:
-rwxr-xr-x 1 root wheel 609960 Nov 1 02:29 /mnt/EFI/BOOT/bootaa64.efi
Is it prudent to simply substitute the newer version for the older?
> Have you been updating
> it via copying /boot/loader.efi to it as > /boot/loader.efi is updated?
Not following here. Loader.efi appears to be a file and seems to update
during normal build/install cycles. It's unclear where bootaa64.efi comes
from; there's only one copy in the filesystem after repeated OS update cycles.
Thanks for reading!
bob prohaska
>
> 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 at 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)
>
>
More information about the freebsd-arm
mailing list