Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

[This was composed yesterday but accidentally not sent.]

On 2022-Oct-10, at 19:37, Mark Millard <[email protected]> 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 <[email protected]> wrote:
> 
>> On 2022-Oct-9, at 21:44, Mark Millard <[email protected]> wrote:
>> 
>>> On 2022-Oct-9, at 19:29, Mark Millard <[email protected]> wrote:
>>> 
>>>> On 2022-Oct-9, at 17:28, bob prohaska <[email protected]> wrote:
>>>>> . . .
>>>>> Is it possible to boot ARMv7 on a Pi3 or Pi4?
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>>> 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. 
>>>> 
>>>> 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.
>>>> 
>>>> I'm not sure how much RAM would be put to use on a RPi4B with
>>>> more than 2 GiBytes of RAM.
>>> 
>>> My experiments indicate that the armv7 u-boot ( u-boot-rpi2 )
>>> does not deal with the RPi4B's USB:
>>> 
>>> U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000)
>>> 
>>> 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 
>>> 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
>>> . . .
>>> 
>>> 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).
>>> 
>> 
>> My experiments with:
>> 
>> A) An RPi2B v1.1 (so actual armv7)
>> and:
>> B) An RPi3B (so aarch64, but a pre-RPi4B design)
>> 
>> are incomplete but both work the same for as far
>> as I got them to go. I got them to:
>> 
>> 
>> . . .
>> Using DTB provided by EFI at 0x7ef6000.
>> Kernel entry at 0x36a00200...
>> Kernel args: (null)
>> 
>> 
>> and there is no more output.
>> 
>> This means that the following all happened:
>> 
>> 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.
>> 
>> Beyond that I do not know what is going on.
>> 
>> Still, unlike the RPi4B, the RPi3B looks to be handled
>> by the armv7 context (at least for as far as I got).
>> 
>> 
> 
> Well, I tried:
> 
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> 
> 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.)
> 
> So I tried using just microsd card media produced with dd:
> 
> A) The RPi2B v1.1 hangs the same sort of way again.
> 
> There is no .dtb for the RPi3B unless added to the
> microsd card. So adding it and trying:
> 
> B) The RPi3B hangs the same sort of way again.
> 
> So it looks like RPi2B v1.1 armv7 support is broken on FreeBSD.
> 
> As I remember, HPS's patch is not in place yet in stable/13 .
> 

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: 
  Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7,
  PXN, LPAE, Coherent Walk
Optional instructions: 
  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.armv7/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=     ${.CURDIR}/../u-boot-master
 
+EXTRA_PATCHES= ${.CURDIR}/files/
 PATCHFILES+=   939129/raw
 
 WWW=           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.)

===
Mark Millard
marklmi at yahoo.com