Date: Tue, 11 Oct 2022 09:27:54 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-uboot@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <616CC0AF-C986-46F9-959C-1B11BE10649E@yahoo.com> In-Reply-To: <3AA3A257-50DA-4896-84CF-1339AF7F3854@yahoo.com> References: <EEC43DA1-6B68-4FDD-A68A-A3055E86E407@googlemail.com> <20221003004624.GA3381@www.zefox.net> <B32F06DD-DFAF-4CB7-A973-7C07846F6E8E@yahoo.com> <20221004001857.GA7109@www.zefox.net> <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com> <20221004192707.GA11488@www.zefox.net> <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com> <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net> <D2BCC480-2165-4050-8F9A-590343608BCB@yahoo.com> <20221010002828.GA4232@www.zefox.net> <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com> <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com> <376089E4-8450-4842-B24D-1D6334D504CC@yahoo.com> <3AA3A257-50DA-4896-84CF-1339AF7F3854@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[This was composed yesterday but accidentally not sent.] On 2022-Oct-10, at 19:37, Mark Millard <marklmi@yahoo.com> wrote: > [Summary of armv7 experiments: it looks like the RPi2B v1.1 armv7 > support is broken on FreeBSD's main [so: 14].] Turns out to be that main's EFI loader is the source of the failure. Using the EFI loader from 13.1-STABLE instead works just fine with the otherwise-main context. > On 2022-Oct-10, at 00:08, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On 2022-Oct-9, at 21:44, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> On 2022-Oct-9, at 19:29, Mark Millard <marklmi@yahoo.com> wrote: >>>=20 >>>> On 2022-Oct-9, at 17:28, bob prohaska <fbsd@www.zefox.net> wrote: >>>>> . . . >>>>> Is it possible to boot ARMv7 on a Pi3 or Pi4? >>>>=20 >>>> There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would >>>> need to be in use U-Boot and the ARMv7 RPi* firmware files would >>>> need to be present. >>>>=20 >>>> https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end = of >>>> the BETA) is from this year. Prior to that the official support was >>>> all ARMv7 or ARMv6 based. >>>>=20 >>>>> That would let me >>>>> set up a single SATA drive that could be tested on any host in >>>>> my collection with any candidate USB-SATA bridge.=20 >>>>=20 >>>> As I understand, such could work. But I've not tested such >>>> combinations. I doubt that those FreeBSD folks that developed >>>> the RPi4B support did much testing of armv7 use then or since. >>>>=20 >>>> I'm not sure how much RAM would be put to use on a RPi4B with >>>> more than 2 GiBytes of RAM. >>>=20 >>> My experiments indicate that the armv7 u-boot ( u-boot-rpi2 ) >>> does not deal with the RPi4B's USB: >>>=20 >>> U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000) >>>=20 >>> DRAM: alloc space exhausted >>> 947 MiB >>> RPI 4 Model B (0xd03114) >>> Core: 195 devices, 9 uclasses, devicetree: board >>> MMC: mmc@7e300000: 3, emmc2@7e340000: 0 >>> Loading Environment from FAT... Card did not respond to voltage = select! : -110 >>> In: serial >>> Out: serial >>> Err: serial >>> Net: No ethernet found. >>> starting USB... >>> No working controllers found >>> Hit any key to stop autoboot: 0=20 >>> 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 >>> starting USB... >>> No working controllers found >>> USB is stopped. Please issue 'usb start' first. >>> starting USB... >>> No working controllers found >>> . . . >>>=20 >>> Also, if I had a EtherNet dongle plugged in, it did not >>> even get that far. Note the "No ethernet found" as well >>> (no dongle present). >>>=20 >>=20 >> My experiments with: >>=20 >> A) An RPi2B v1.1 (so actual armv7) >> and: >> B) An RPi3B (so aarch64, but a pre-RPi4B design) >>=20 >> are incomplete but both work the same for as far >> as I got them to go. I got them to: >>=20 >>=20 >> . . . >> Using DTB provided by EFI at 0x7ef6000. >> Kernel entry at 0x36a00200... >> Kernel args: (null) >>=20 >>=20 >> and there is no more output. >>=20 >> This means that the following all happened: >>=20 >> A) RPi* firmware got U-Boot started. >> B) U-Boot got the FreeBSD loader started. >> C) The FreeBSD loader got as far as those messages >> after loading the kernel. >>=20 >> Beyond that I do not know what is going on. >>=20 >> Still, unlike the RPi4B, the RPi3B looks to be handled >> by the armv7 context (at least for as far as I got). >>=20 >>=20 >=20 > Well, I tried: >=20 > = FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img >=20 > and I get the same sort of hangup on both the RPi2B v1.1 and the > RPi3B when booting with the FreeBSD loader, kernel, and world on > the USB media. I've tried 2 types of USB media, both got the same > result. (microsd card media is involved in the early stages.) >=20 > So I tried using just microsd card media produced with dd: >=20 > A) The RPi2B v1.1 hangs the same sort of way again. >=20 > There is no .dtb for the RPi3B unless added to the > microsd card. So adding it and trying: >=20 > B) The RPi3B hangs the same sort of way again. >=20 > So it looks like RPi2B v1.1 armv7 support is broken on FreeBSD. >=20 > As I remember, HPS's patch is not in place yet in stable/13 . >=20 So, armv7 FreeBSD main booting the RPi3B, other than the EFI loader being from 13.1-stable . The FreeBSD EFI loader, kernel, and world being on a USB3 NVMe SSD (used via a USB2 port): . . . CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080) CPU Features:=20 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, PXN, LPAE, Coherent Walk Optional instructions:=20 SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 . . . # uname -apKU # Note: Output line split manually for better readability FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #48 main-n258174-89a2ef4d5226-dirty: Sat Sep 24 19:37:56 PDT 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400070 1400070 So, while U-Boot prevents RPi4B's from booting via armv7 FreeBSD, RPi3B's can boot okay (absent other FreeBSD issues, anyway). The microsd card has all the required RPi* firmware ( including the bcm2710-rpi-3-b.dtb ) and has u-boot.bin . The microsd card does not have EFI/BOOT/bootarm.efi . Note: For my media, u-boot.bin is my patched version, including the Makefile needing the following to cause the patch file to be used: # git -C /usr/ports diff sysutils/u-boot-rpi2/ diff --git a/sysutils/u-boot-rpi2/Makefile = b/sysutils/u-boot-rpi2/Makefile index 90c4e4d91827..9eca905f87c6 100644 --- a/sysutils/u-boot-rpi2/Makefile +++ b/sysutils/u-boot-rpi2/Makefile @@ -1,5 +1,6 @@ MASTERDIR=3D ${.CURDIR}/../u-boot-master =20 +EXTRA_PATCHES=3D ${.CURDIR}/files/ PATCHFILES+=3D 939129/raw =20 WWW=3D https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi Also, I happen to use the RPi* firmware vintage: # strings /boot/efi/start.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 18:17:07 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Aug 3 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 40787ee5905644f639a2a0f6e00ae12e517a2211 (clean) (The most recent that my limited tests showed as FreeBSD handling without crashing for the few models that I have access to, at least back when I did those tests.) =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?616CC0AF-C986-46F9-959C-1B11BE10649E>