Date: Mon, 10 Oct 2022 23:13:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is broken for RPi2 v1.1 (so: armv7) Message-ID: <FBB1CDA6-F1F8-47FB-B79D-86E4CCEA3FAF@yahoo.com> In-Reply-To: <FC871551-7C49-4751-8763-2E8F82C1480A@yahoo.com> References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com> <D9B791B7-106A-402E-AD8C-F811EB315560@yahoo.com> <CANCZdfoJ=E=ef86PRaYsvgXWLAu=AdbN%2B_kiv0vPhKVksqPY%2Bg@mail.gmail.com> <FC871551-7C49-4751-8763-2E8F82C1480A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Oct-10, at 22:50, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Oct-10, at 21:08, Warner Losh <imp@bsdimp.com> wrote: >=20 >> On Mon, Oct 10, 2022, 10:00 PM Mark Millard <marklmi@yahoo.com> = wrote: >> [Summary: it looks to be FreeBSD main's EFI loader that is >> at issue for armv7 RPi2B v1.1 booting not working.] >>=20 >> On 2022-Oct-10, at 20:04, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> I put: >>>=20 >>> = FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img >>>=20 >>> on a microsd card via dd and tried to boot a RPi2 v1.1. it >>> hung up after: >>>=20 >>> Using DTB provided by EFI at 0x7ef6000. >>> Kernel entry at 0x36a00200... >>> Kernel args: (null) >>>=20 >>> (A "-" might show in the next line.) >>>=20 >>> So I tried: >>>=20 >>> = FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img >>>=20 >>> on the microsd card instead. It worked just fine. (Thus the >>> RPi2B v1.1 is not broken.) >>>=20 >>> I did this experiment because recent testing for other >>> reasons of somewhat older main vintages that I'd built >>> also showed such failures. This test shows official >>> builds also have the problem. >>>=20 >>> I've no clue how long this issue has been around. It >>> been a very long time since the RPi2B v1.1 had been >>> powered on. >>>=20 >>>=20 >>> Note: The arm-armv7-GENERICSD images include the RPi2B >>> v1.1 related RPi* firmware and u-boot, in addition to >>> an installed FreeBSD EFI loader and a kernel and a >>> world. Historically it was supposed to just work for >>> RPi2B v1.1's.=20 >>=20 >> I mounted the main [so: 14] media to /mnt and >> copied /mnt/EFI/BOOT/bootarm.efi to >> /boot/msdos/EFI/BOOT/bootarm.efi . >>=20 >> The result makes the 13.1-STABLE media fail in >> the same sort of manor as 14-CURRENT did. >>=20 >> So I tried an experiment going in the other >> direction: copying 13.1-STABLE's >> EFI/BOOT/bootarm.efi into a main [so: 14] >> context that had been failing to boot. >> It then boots fine. >>=20 >> main's armv7 EFI/BOOT/bootarm.efi is broken, at >> least for RPi2B v1.1 systems. >>=20 >> Can you write a brief summary so I can recreate? >=20 > This is an independent report from the exchange > with Bob P. about his overall problems. This has > its own subject text. There is not much to this > specific report. Messages with other subjects > should be ignored for this issue. USB media is > not involved here: a microsd card is sufficient > to see the problem. >=20 >> And are you sure it's a booting issue and not a console issue? >=20 > No clue for your distinction. But, being serial console > based until ssh is possible for my context, I classify > serial-console-broken as a booting issue. (For example, > not being able to identify the DHCP address assigned > if it did make it that far.) >=20 > It may be that the snapshots need to be modified to deal > with EFI loader changes --instead of changes to the loader > needing to be made. I'm not trying to specify which. >=20 >> I can't make heads or tails of this whole thread. I need something = simple, that's like 5 steps with version numbers. >=20 > The images listed in the above are the official snapshots. > I've no way to be more explicit than the file names of the > official snaphot images. The use of 20220930 (date) instead > of 20221007 for main's snapshot was an accident and I could > try the one with the more recent date if needed. >=20 > If you have RPi2B v1.1 (so: armv7) access, just try to boot: >=20 > = FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img >=20 > via serial console usage, no video connection present. (I > did not try a video connection as that is not my type of > context.) >=20 > To make it work for that context, replace the EFI/BOOT/bootarm.efi > by the one from: >=20 > = FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img >=20 > and then retry booting the result. I've tried the snapshot: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20221007-b05b1ecbef0-258483.img and got the same boot failure when it is what is on the microsd card (no EFI loader replacement). I got access to a display and HDMI cable and tried booting with it connected. The last text it displays matches the last text on the serial console: Using DTB provided by EFI at 0x7ef6000. Kernel entry at 0x33800200... Kernel args: (null) - (ignoring, possibly, the "-"). =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?FBB1CDA6-F1F8-47FB-B79D-86E4CCEA3FAF>