Upgrading u-boot on an rpi3

[bob prohaska]

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)
> 
>