Date: Mon, 3 Jul 2023 07:48:18 -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: <5FB0D416-8AEE-403E-8EFB-E41DF321BE54@yahoo.com> In-Reply-To: <89D2358E-93BB-489C-B19A-5B5BC6F5BFD7@yahoo.com> References: <ba6aafc8-b3b4-dd22-ea31-0d8b9e538a93@thegalacticzoo.com> <89D2358E-93BB-489C-B19A-5B5BC6F5BFD7@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> 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 ** >=20 > 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. >=20 > (Note: the message content itself is misleading > compared to the actual internal problem in U-Boot.) >=20 > You can replace the u-boot.bin with a copy of the > older one in: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-= RELEASE-arm64-aarch64-RPI.img.xz >=20 > Similarly if you have other older copies of the > arm64-aarch64 RPI u-boot.bin on other of your > existing media. >=20 >> 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. >=20 > Replacing bootaa64.efi will not fix anything. >=20 >> 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. >=20 > 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. >=20 >> I am interested to learn how to use this nice 2023.01 U-BOOT and = learn to debug by PXE booting the Raspberry Pi. >=20 > 2023.01 is not nice for 8 GiByte RPi4 variants. > It is broken. >=20 >> Is there a website tutorial about using U-BOOT> to test and learn = about your ARM64 Hardware? RTFM manual >=20 > You can not make 2023.01 work. Older or newer. > Older is easier to get copies of. >=20 >> Anyone else encountering this particular issue from a snapshot image? >=20 > Multiple people have hit this issue in the past > and the freebsd-arm list history has the records > about it. >=20 >> = 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 >=20 > 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. >=20 >> 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 ** >=20 > This is the misleading message that is actually > caused by running out of reserved[?] but needing > more. >=20 >> 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 >=20 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=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin [all] # # Local addition that avoids USB3 SSD boot failures that look like: # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ? # WARNING, not sufficient for "boot -s": that needs the full = force_turbo=3D1 initial_turbo=3D60 [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 # hdmi_safe=3D0 =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?5FB0D416-8AEE-403E-8EFB-E41DF321BE54>