Upgrading u-boot on an rpi3

[Mark Millard]

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:
>> 
>> 
>> 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.

Arm boards other than RPi*'s tend to involve putting materials
outside any file system on the media that is involved.

Example /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
was used above.

Note the dd command below and the bs= and seek= and the file
name.

# more /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
U-Boot loader for OrangePi Plus2E.

To install this bootloader on an sdcard just do :
dd if=$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=sync

This version is patched so that:
 * API features are enabled.
 * A boot.scr (U-Boot script) that loads ubldr.bin and execute it is included

For information about running FreeBSD on Allwinner boards, see
https://wiki.freebsd.org/FreeBSD/arm/Allwinner

WWW: http://www.denx.de/wiki/U-Boot


Such is not involved for the RPi*'s: all the material
goes in a file system, no dd involved.


>> METHOD=uboot-file
>> FILES="u-boot.bin"

The above was an example from an RPi* .

Note the "uboot-raw" earlier vs. "uboot-file" here.
That indicates the outside file system vs. inside
file system status.

>> (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?

You may want to extract a more modern one from a snapshot
if that does not work.

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

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

> . . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)