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

Reply: Fred G. Finster: "[SOLVED] Thanks Mark! Re: USB Flash drive booting from June 22,2023 RPI Snapshot FreeBSD 14.0"
In reply to: Mark Millard : "Re: USB Flash drive booting from June 22,2023 RPI Snapshot FreeBSD 14.0"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 03 Jul 2023 14:48:18 UTC
On Jul 3, 2023, at 07:16, Mark Millard <marklmi@yahoo.com> wrote:

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

Separately from u-boot.bin I also use a modified
config.txt (at least for my type of boot devices).
See the comments about use of
initial_turbo/force_turbo. force_turbo required
use of over_voltage for reliability. You may
or may not have the issue that leads to these
changes (additions).

Part of the reason for various settings is
FreeBSD's use of older RPi* firmware. That in
turn means that the RPi* firmware documentation
is inaccurate about various defaults for the
vintage that FreeBSD uses. One has to look up
older documentation to see the accurate defaults
for what FreeBSD is using.

# more /boot/efi/config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi4]
hdmi_safe=1
armstub=armstub8-gic.bin

[all]
#
# Local addition that avoids USB3 SSD boot failures that look like:
# uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
# uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
# WARNING, not sufficient for "boot -s": that needs the full force_turbo=1
initial_turbo=60
[pi4]
over_voltage=6
arm_freq=2000
sdram_freq_min=3200
force_turbo=1
#
hdmi_safe=0


===
Mark Millard
marklmi at yahoo.com