Re: USB Flash drive booting from June 22,2023 RPI Snapshot FreeBSD 14.0

On Jul 3, 2023, at 05:31, Fred G. Finster <fred@thegalacticzoo.com> wrote:

> I downloaded this June 22, 2023 version of the  RPI snapshot and burned to a USB flash drive to test on my Raspberry Pi 4B with 8 GB
> 
> https://www.freebsd.org/where/
> 
> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
> 
> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230622-b95d2237af40-263748.img.xz
> 
> Is there a recipe that some machine follow to build this image? Can I have that recipe to verify the build process?  What should I do about
> 
> the
> 
> It try to TFTP  boot an image,  I was not setup for yet.  I will google and find some docs and webpages to help me out.
> 
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> ** Reading file would overwrite reserved memory **

That message is from the u-boot.bin stage, before
FreeBSD itself is involved but after the RPi*
firmwmare. FreeBSD is currently using a vintage of
U-Boot that is broken for 8 GiByte RPi4's. FreeBSD
has not updated to use the more recent fixed
vintaeg of U-Boot. This is a known issue that has
been reported on multiple times on the lists.

(Note: the message content itself is misleading
compared to the actual internal problem in U-Boot.)

You can replace the u-boot.bin with a copy of the
older one in:

http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz

Similarly if you have other older copies of the
arm64-aarch64 RPI u-boot.bin on other of your
existing media.

> Failed to load 'efi/boot/bootaa64.efi'
> No UEFI binary known at 0x00080000
> EFI LOAD FAILED: continuing...
> 
> 
> Yes, I can take a working  bootaa64.efi file and replace this one version  Then see if I can boot my raspberry pi 4B.

Replacing bootaa64.efi will not fix anything.

> What else do you suggest to do to check or verify.  My system was booting the older version of FreeBSD 14.0 from my
> 
> 500GB SSD.  See my blogpost for details.  Yes, snapshots of 14.0-CURRENT can have problems, so I just wish to share my experience.
> 
> I am afraid I over looked some small simple detail that I did not change or setup.  My apology in advance.

You did not overlook anything. FreeBSD is just
bundling a bad version of u-boot.bin in its
modern images, broken specifically for 8 GiByte
RPi4 variants.

> I am interested to learn how to use this nice 2023.01 U-BOOT and learn to debug by PXE booting the Raspberry Pi.

2023.01 is not nice for 8 GiByte RPi4 variants.
It is broken.

> Is there a  website tutorial about using U-BOOT>  to test and learn about your ARM64 Hardware?  RTFM manual

You can not make 2023.01 work. Older or newer.
Older is easier to get copies of.

> Anyone else encountering this particular issue from a snapshot image?

Multiple people have hit this issue in the past
and the freebsd-arm list history has the records
about it.

> https://ghostbsd-arm64.blogspot.com/2022/02/booting-500-gb-ssd-on-freebsd-arm64-140.html
> 
> https://ghostbsd-arm64.blogspot.com/2022/09/freebsd-140-compiling-kernel-for.html
> 
> 
> 
> Sorry to share this long listing with details:
> 
> Here is a a partial listing of the board dump  bdinfo command issued to 'U-BOOT>'  prompt
> 
> lmb_dump_all:
>  memory.cnt  = 0x3
>  memory[0]      [0x0-0x3b2fffff], 0x3b300000 bytes flags: 0
>  memory[1]      [0x40000000-0xfbffffff], 0xbEFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> ** Reading file would overwrite reserved memory **
> Failed to load 'efi/boot/bootaa64.efi'
> No UEFI binary known at 0x00080000
> EFI LOAD FAILED: continuing...c000000 bytes flags: 0
>  memory[2]      [0x100000000-0x1ffffffff], 0x100000000 bytes flags: 0
>  reserved.cnt  = 0x8
>  reserved[0]    [0x0-0xfff], 0x00001000 bytes flags: 0
>  reserved[1]    [0x7ef0000-0x7f0ffff], 0x00020000 bytes flags: 0
>  reserved[2]    [0x39c28000-0x3b2fffff], 0x016d8000 bytes flags: 0
>  reserved[3]    [0x3ac3c380-0x3b0fffff], 0x004c3c80 bytes flags: 0
>  reserved[4]    [0x3ee5c0a0-0x3ee5c164], 0x000000c5 bytes flags: 4
>  reserved[5]    [0x40000000-0xfbffffff], 0xbc000000 bytes flags: 0
>  reserved[6]    [0xfe100000-0xfe100fff], 0x00001000 bytes flags: 0
>  reserved[7]    [0x100000000-0x1ffffffff], 0x100000000 bytes flags: 0

Turns out the problem in u-boot.bin it tied to
how many of the reserved[?] are actually needed
at one stage: it ran out but needed more. They
forgot to increase the allowed count when then
made other changes that caused usage of more
reserved address ranges.

> devicetree  = board
> arch_number = 0x0000000000000000
> TLB addr    = 0x000000003b0f0000
> irq_sp      = 0x000000003ac40820
> sp start    = 0x000000003ac40820
> Early malloc usage: 878 / 2000
> U-Boot> boot
> Card did not respond to voltage select! : -110
> MMC Device 1 not found
> no mmc device at slot 1
> MMC Device 2 not found
> no mmc device at slot 2
> 
> Device 0: Vendor: Verbatim Rev: PMAP Prod: ClickUSB
>             Type: Removable Hard Disk
>             Capacity: 14776.0 MB = 14.4 GB (30261248 x 512)
> ... is now current device
> Scanning usb 0:1...
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> ** Reading file would overwrite reserved memory **

This is the misleading message that is actually
caused by running out of reserved[?] but needing
more.

> Failed to load 'efi/boot/bootaa64.efi'
> No UEFI binary known at 0x00080000
> EFI LOAD FAILED: continuing...
> BOOTP broadcast 1
> DHCP client bound to address 192.168.1.7 (8 ms)
> *** Warning: no boot file name; using 'C0A80107.img'
> Using ethernet@7d580000 device
> TFTP from server 192.168.1.1; our IP address is 192.168.1.7
> Filename 'C0A80107.img'.
> Load address: 0x1000000
> Loading: T T T T T
> Abort
> missing environment variable: pxeuuid



===
Mark Millard
marklmi at yahoo.com