From nobody Mon Jul 03 14:48:18 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvphR74bRz4m13X for ; Mon, 3 Jul 2023 14:48:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvphQ4CKRz3wNx for ; Mon, 3 Jul 2023 14:48:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MGPGhJhR; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688395715; bh=+H8nyho9+9D0frDjRSBAl/0IadG1hOjxG8rkZ80xtZQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MGPGhJhRL7+I9XSwBS6aj1GFdtN2sdScZks/9VO0GRthdLp+BMw/DR5sJeQE9lZR9OGcf8SY8/ojzMLYKZ8kMKrUK3hnb1AUPxvW/LfFwzOVvIcgb53upR2Kunh/ljPeGsJfMDFVpeIHI6JzynLWU6Vs8u8aCo+LhRC7VCYuYxf+gxdiqetE66Nfse3shMhQ8GdnRqzh9fkpgEfOfadl4GMCtD2obtz0r6W8n+zYzUapv/KuzTwp106R/KBw5lyhQivDkvTCy2JpOJrrHw+4md6CnaYhwCQs7u+rrP1qDhd0bMxlN5NFsFWhxT22NtfqLDkXExzy2M38eDOyhNzQ6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688395715; bh=6zHs+/+6jLch1R8tDJGBNBXtsfzdaQVJNNyOrSlI4jw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hwyOyn2IE47LpVREy/8Iy9txRNfkw0PQHGyKwvImSBIXi6sZ/vM1S6Xfmxn/GPgtb+bPFI+s4BOibFH5lI3vF1c8sKylSi77W5NuBzXZToaTl1HVfHarJfEzXWvkM4pVaTYLWzGyd2HPD6nhloqJMRVUVvjKFhjKcnkrvtHzxhr/q1EQxrwRhMk5I5buQlLdRo6EPpaa8sCFAuCbrPGqRGxuzmQNVcMsIQpChyD6J1wcMDgrJqr3oIkqWC2qplDX9VzOREfMKBOwW66Hi4kWnyAqOeIbNWg4Wl7dfciJcJD92j5rFcS/ITe8wufVR8MFk0gx+L/oxQiPkO6ux+mW1A== X-YMail-OSG: rqloOMEVM1nLNAWqi85IS8xjTDiwBIlMrV29FhIQ_M5DvVdAZ68D7udyU9BdklK Wm_dQ6HnU0efKRnlD3QixxW_UvKWk5VrZRyaCWVd63O9e9Zu5VnFQlg913WmBJRw2AIWQBInclv7 CO5_IQJjpMNqT_4vOTWqf4HQpCS5zE8ftGYrJchrysombLI0trHnW9iCiB4BQfzAP3h1d7dOZUOV EyQK2O2GjoIWC6potAOcax_g7bS6OAUpgNSq2TWZQkPhqgGqRYrruW8Niy3leaiaJbKCtUVvclQk TbVSlwi80n8p7hkZapKSYIb4J.0a4.Jd5MfqfeRwZgAdHrLM6SPW3K0oYHHUgt4z2dZDhek2QOF7 0fSYhSg9oXlTAmXsJQsk9tVMRS4lPbBylV4MqlBr3aoWMpyCNn.Qrjpvy1FiotFjHNIks5P1WvH3 yYWFrvtwtF.YKglnap9xamYv5rMTQ04o8HunDocbFoV_wgPncUtUrFJ1KCjitH1xEdUWvEgsc8R_ NE.cZXkAKVshISYVqmvhSCUMYjxdfnprv6FVgyYCIYpTDlDPWQ8b1G4lALj6XSrE6Wh2ysLhTAsM ogyDnjupZmyUBkYKWbPh4_8pvB_wNLdAAqDlGAUyIeguKqQEc9LwNwH7041xpfN5KZPW08lzADe5 x186HUw7lit8F7.zPZuImlPAbBwNhBx3WEtx75xx4b_kuM69cJEr5RKzqz0aTkNjw9uTKT4FczL_ gVMeTdmv5kLhW5d6l6jDhhrc6A1hfOBciUxOxOrGsk9A56pOyo5o2xyepOBYTFjkvPFJHRhHAZsl dDviZAUw7IzcmCuYTU3i7Px7d6ugBsMJQZD6nIZhf13iPf.0Zu4p1x08EZoQhBu5o.7nskSmLAUL 0b7VNKDQsXImvJboprCXapZagtf8SAkFYqMxynOOFKRdNVQ.hrrgvsZ1MtQHzn.PmV_2COckgJ_e XFztR7S_o0UxNqE3T.YQ7emTJ_OX7QlABHUbMdCtVNxcTXd1ZbU42W5DbBDzLkRiLIHfiwW3tdd3 oXKFEugNrYhXBDw_PN2LDbRsdQJ9bcj2eb0Cvniur2W2ap23T3iS5FZSv4IwHej62bxwcocdJT.o XJeL8dm1RWP.1taqeQVmKnTwYh0zxfVAUXxHKMRosqIOWemGlgD5bUHBJym3wIVqU9ZzR09PFvtf jcbN7agZmPi4RuQtzPZJ4jQp69B1e0HCUpgX0PMGQIUzzNK0ZaEvuWIZETcRF5uj4wDznmKjaGYZ uIt5X341UizRBT8auTfwhsXbzTDKEYD1u2jhNMg6JDmKzqPoKxVkdW_Tuuhe89nBQibp5jZ9YiVw 3NMGagC0Y0hOyqqZJLP2lBEGMXEHCHdNMNBwhuvCnC8iFPb7dnB13CwY0zIYY49MxDPw1PqMFfC8 tRIyfQrjRSfFf6G3o7UXOqCCFiNihBFMiYkotOIVOn5DAWV9YW28OC.vpyqA_emtjiuIY30CGQrE k1Wy2FmCFKOTGQOk9beS7sWKZPw4PwqFWR51kvhqdD_dGDaP3YC2178M4krHZx21BLX3C_2MrTw0 bfXtVIUIVYOihiHC49JMH99AEMlj36qR5eBvKNtN9632iU8ZmW_juGskIpyLw7AWnA1jHlqEh8xt CVi_AN80HbgTRVKLdtsSNKrgnfMKKbgW.YCCqTwsT9_VwjjHxbVfP6FOMFFodX7rqJf4OLg5yjOl tArVdzazZPI8Dgt3pZlvxHlRQIE64bJcs2cTVFzSLbIdDJ911dpMcTWzskSmiWQ0qeHjbbm5RJNs meehb2jDKSCr1tChqgDPJWg8NYc4xSQj9hGf0QRb3yFPJjPFiUwM4Mcd7J31Iuk8TOt8FI4zvabG LCoQ7XC08CPYijV8yMHo_BxXYo3rVLxkHYkOXUGGq_UzgRlzdzTiCW2QGrinrFvYH.4LaIlwfTMJ 26EryDgpb7Hx_wCu1HVhDXAZOWku67o3YZthxsIjuDuuWTWg6bWBQ3.RydTh3NoY2jSaYWll974F gH41Zltp_KGs4S8w26MpO2yW61eVxESRjK4iQnnUbeVyWgNcyxwMEVtFsuDQG_Fez7__JydazTCh zfKo1izkThJAS6cxMO2bUE3KhaPkVdjXWF.t.eGLdsSEGppu0baXFS0GmbxWNXjfBI.zpURtuCCy dLLA1fl309_TJkTt3SV25_V3W.FWXUWrG5uU81KxYRLkMukzypDXRtZyFDo8Fp.3wDQjTRTLjkbX i83lTdygkATbx1GlK3bCs_li4SpHd9zeC35l_lbbJiRPXUfwwXy39MIBeczBeKDVH9VupaCQX68T agg-- X-Sonic-MF: X-Sonic-ID: fbadae93-fd7d-49c5-89b4-f857726b380a Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Jul 2023 14:48:35 +0000 Received: by hermes--production-bf1-5d96b4b9f-wmng2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 373e9006917e3caac556013ca7177a73; Mon, 03 Jul 2023 14:48:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: USB Flash drive booting from June 22,2023 RPI Snapshot FreeBSD 14.0 From: Mark Millard In-Reply-To: <89D2358E-93BB-489C-B19A-5B5BC6F5BFD7@yahoo.com> Date: Mon, 3 Jul 2023 07:48:18 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FB0D416-8AEE-403E-8EFB-E41DF321BE54@yahoo.com> References: <89D2358E-93BB-489C-B19A-5B5BC6F5BFD7@yahoo.com> To: "Fred G. Finster" X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-2.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_SHORT(-0.15)[-0.151]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from] X-Rspamd-Queue-Id: 4QvphQ4CKRz3wNx X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Jul 3, 2023, at 07:16, Mark Millard wrote: > On Jul 3, 2023, at 05:31, Fred G. Finster = 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