Upgrading u-boot on an rpi3

[Mark Millard]

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