Upgrading u-boot on an rpi3

[bob prohaska]

On Wed, Mar 18, 2020 at 11:02:43AM -0700, Mark Millard wrote:
> 
> 
> On 2020-Mar-18, at 10:23, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> > On Tue, Mar 17, 2020 at 11:42:09PM -0700, Mark Millard wrote:
> >> 
> >> 
> 
> >> 
> >> 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?
> 
> You may want to extract a more modern one from a snapshot
> if that does not work.
>
 
Turns out that the version of bootaa64.efi from the 12.x snapshot did
the trick. 

> >> 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. 
> 
> For the ARM boards involved, efi/boot/bootaa64.efi is a
> copy of /boot/loader.efi . The loader copy used in booting
> is placed on the msdosfs, not on ufs/zfs.
> 

Ahh, now bells are ringing. IIRC there were some messages issued
to this effect during either make or make install for u-boot-rpi3,
at least formerly. 



> Example from the RPi4 context:
> 
> # file /boot/loader.efi
> /boot/loader.efi: MS-DOS executable PE32+ executable (EFI application) Aarch64, for MS Windows
> 
> # file /boot/efi/EFI/BOOT/bootaa64.efi 
> /boot/efi/EFI/BOOT/bootaa64.efi: MS-DOS executable PE32+ executable (EFI application) Aarch64, for MS Windows
> 

Thank you very much!

bob prohaska