Date: Mon, 3 Jul 2023 07:16:25 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Fred G. Finster" <fred@thegalacticzoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: USB Flash drive booting from June 22,2023 RPI Snapshot FreeBSD 14.0 Message-ID: <89D2358E-93BB-489C-B19A-5B5BC6F5BFD7@yahoo.com> In-Reply-To: <ba6aafc8-b3b4-dd22-ea31-0d8b9e538a93@thegalacticzoo.com> References: <ba6aafc8-b3b4-dd22-ea31-0d8b9e538a93@thegalacticzoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >=20 > https://www.freebsd.org/where/ >=20 > https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ >=20 > = https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeB= SD-14.0-CURRENT-arm64-aarch64-RPI-20230622-b95d2237af40-263748.img.xz >=20 > 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 >=20 > the >=20 > 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. >=20 > 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... >=20 >=20 > 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 >=20 > 500GB SSD. See my blogpost for details. Yes, snapshots of = 14.0-CURRENT can have problems, so I just wish to share my experience. >=20 > 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 >=20 > = https://ghostbsd-arm64.blogspot.com/2022/09/freebsd-140-compiling-kernel-f= or.html >=20 >=20 >=20 > Sorry to share this long listing with details: >=20 > Here is a a partial listing of the board dump bdinfo command issued = to 'U-BOOT>' prompt >=20 > lmb_dump_all: > memory.cnt =3D 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 =3D 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 =3D board > arch_number =3D 0x0000000000000000 > TLB addr =3D 0x000000003b0f0000 > irq_sp =3D 0x000000003ac40820 > sp start =3D 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 >=20 > Device 0: Vendor: Verbatim Rev: PMAP Prod: ClickUSB > Type: Removable Hard Disk > Capacity: 14776.0 MB =3D 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 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89D2358E-93BB-489C-B19A-5B5BC6F5BFD7>