Re: armv6/armv7/aarch64 vs. FreeBSD images (retitled from an arch reply, moving to freebsd-arm list)

In reply to: Mark Millard : "armv6/armv7/aarch64 vs. FreeBSD images (retitled from an arch reply, moving to freebsd-arm list)"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 16 Dec 2022 00:26:30 UTC
On Dec 13, 2022, at 22:45, Mark Millard <marklmi@yahoo.com> wrote:

> Julian H. Stacey <jhs_at_berklix.com> wrote on
> Date: Wed, 14 Dec 2022 02:22:10 UTC :
> 
>> Hi, Reference:
>>> From: Mark Millard <marklmi@yahoo.com>
>>> Date: Tue, 13 Dec 2022 15:52:16 -0800
>> 
>> . . . 
>> 
>> Extending wordings associated with each Pi dd image, would be very
>> welcome, to specificaly list all hardware version of a Pi each image
>> of v6, v7, aarch64, the image should boot.
> 
> For FreeBSD support, a U-Boot build that is
> compatible is needed. U-Boot is via ports, with
> only a few preassembled combinations of U-Boot
> variant and FreeBSD produced officially.
> (Statements not limited to RPi*'s.) U-Boot
> materials are not part of FreeBSD but are
> used (even: needed) by FreeBSD.
> 
> The RPi* firmware has a similar status: it is a
> port: rpi-firmware . It is not part of FreeBSD
> itself. A combination of RPi* firmware, U-Boot
> varient, and FreeBSD are needed overall.
> 
> (The RPi* firmware can adjust some of the 
> Device Tree before handing things over to U-Boot.
> U-Boot can adjust/add more before handing that
> off to the FreeBSD loader. FreeBSD does not
> handle all valid Device Trees from what I can
> tell --and this limits what range of RPi*
> firmware that FreeBSD avoids crashing with.)
> 
> What armv6/armv7/aarch64 RPi's there are/have-been,
> no matter if a RPi*-firmware/U-Boot/FreeBSD combination
> has been shown to work or not:
> (I freely use my own abbreviations of official naming.)
> 
> armv6 (BCM2835/BCM2708):
> RPiA, RPiB, RPiA+, RPiB+,
> CM, RPiZero v1.2, RPiZero v1.3, RPiZeroW
> (Note: https://www.raspberrypi.com/products/ does
> not list any of these as EOL yet. CM3 and CM1
> are listed as "in production but not recommended
> for new designs".)
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> (and no others)
> 
> No one may have evidence of the support status
> for each armv6 above. I've no evidence for
> any of them from anything like modern times.
> 
> The port rpi-firmware has the files below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2708-rpi-b-plus.dtb
> bcm2708-rpi-b-rev1.dtb
> bcm2708-rpi-b.dtb
> bcm2708-rpi-cm.dtb
> bcm2708-rpi-zero-w.dtb
> bcm2708-rpi-zero.dtb
> 
> Note: I do not know how to classify the RP2040 Dual-core Cortex-M0+
> processor parts: they are armv6-M (M is for: microcontroller). So
> I did not list: RPiPico, RPiPicoW, or RP2040. No *.dtb name
> suggests which would support any of them.
> 
> armv7 (BCM2836/BCM2709):
> RPi2B <= v1.1, CM2
> (Note: https://www.raspberrypi.com/products/ list
> it as "in production but not recommended for new
> designs".)
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.*+ FreeBSD image name pattern: *-arm-armv7-GENERICSD*
> (All should work for RPi2B <= v1.1 .)
> (No others)
> 
> Note: *-arm-armv7-GENERICSD* is basically a rename of
> *-arm-armv7-RPI2* (relative to RPi* issues).
> 
> I've no clue if anyone has CM2 evidence.
> 
> The port rpi-firmware has the file below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2709-rpi-2-b.dtb
> 
> The port rpi-firmware does not supply the file:
> 
> bcm2709-rpi-cm2.dtb
> 
> So the CM2 is missing something likely essential.
> (But the *.dtb need not be sufficient by itself.)
> (The file goes back to 2018-Mar-22 for its first
> commit on github.)
> 
> aarch64 (BCM2837/BCM2710 family):
> RPi2B v1.2, RPi3A+, RPi3B, RPi3B+, 
> CM3, CM3Lite, CM3+, CM3+Lite, RPiZero2,
> (BCM2710A1):
> RPiZero2W,
> (BCM2711 family):
> RPi4B, CM4, CM4Lite, CM4S, RPi400
> (Note: https://www.raspberrypi.com/products/ does
> not list any of these as EOL yet. Nor any as
> not recommended for new designs.)
> 
> Note: aarch64 RPi*'s can boot via RapsiOS 32-bit or RaspiOS64.
> (I've no clue if FreeBSD can do similarly for the BCM2711 family
> but it has handled BCM2837/BCM2710 contexts used as armv7
> historically.) ("RaspiOS" is my abbreviation.) In part this is a
> U-Boot issue. RaspiOS and RaspiOS64 do not use U-Boot. U-Boot
> could potentially block FreeBSD from operating for a 32-bit
> addressing OS variant.

I tried using the USB3 FreeBSD media I have for booting both
a RPi2B v1.1 (native armv7) and a OrangePi+2ed by plugging it
into a RPi4B:

U-Boot 2022.10 (Oct 21 2022 - 01:23:47 +0000)

DRAM:  947 MiB
RPI 4 Model B (0xd03115)
Core:  200 devices, 12 uclasses, devicetree: board
. . .
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
. . .
starting USB...
No working controllers found
No ethernet found.
No ethernet found.
U-Boot> 

So U-Boot is not set up to deal with the
RPi4B's differing USB hardware. It did not
make it to the FreeBSD loader. 

Thus, effectively, the BCM2711 family is
limited to aarch64 FreeBSD.

> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.*+ FreeBSD image name pattern: *-arm-armv7-GENERICSD*

The above 3 are not appropriate for the BCM2711
based family.

> 12.* FreeBSD image name pattern: *-arm64-aarch64-RPI3*
> 13.*+ FreeBSD image name pattern: *-arm64-aarch64-RPI*
> 
> Note: *-arm-armv7-GENERICSD* is basically a rename of
> *-arm-armv7-RPI2* (relative to RPi* issues).
> 
> Note: *-arm64-aarch64-RPI* is basically a rename of
> *-arm64-aarch64-RPI3* (relative tp RPi* issues).
> 
> No one may have evidence of the support status
> for each aarch64 above. I have some evidence
> only for RPi2B v1.2, RPi3B, some RPi4B. (All
> work for *-arm64-aarch64-RPI* last I checked.)
> 
> The port rpi-firmware has the files below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2710-rpi-2-b.dtb
> bcm2710-rpi-3-b-plus.dtb
> bcm2710-rpi-3-b.dtb
> bcm2710-rpi-cm3.dtb
> bcm2711-rpi-4-b.dtb
> bcm2711-rpi-400.dtb
> bcm2711-rpi-cm4.dtb
> 
> The port rpi-firmware does not supply the files:
> 
> bcm2710-rpi-zero-2-w.dtb
> bcm2710-rpi-zero-2.dtb
> bcm2711-rpi-cm4s.dtb
> 
> So the RPiZero2, RPiZero2W, and CM4S are missing
> something likely essential. (But the *.dtb need
> not be sufficient by itself.)
> 
>> As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused
>> which image is for which version of Pi hardware.
> 
> The  RPi3B+ should be able to use any of:
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.* FreeBSD image name pattern: *-arm-armv7-GENERICSD*
> 12.* FreeBSD image name pattern: *-arm64-aarch64-RPI3*
> 13.* FreeBSD image name pattern: *-arm64-aarch64-RPI*
> 
> But I've no evidence of my own of the actual results.
> (No access to such a part.)
> 
> The *-arm64-aarch64-* ones are a more complete match
> to the hardware: for example supporting 64-bit
> addressing instead of 32-bit.
> 
>> I previously had some kind of a 3B, & now have a "Pi 3 Model B+",
>> but have not got beyond booting images, starting to customise /etc/
>> & then it crashes yet again, needing yet another dd, & repeat,
>> Being certain one is using the right image would be nice.
> 
> This does not sound normal at all. I expect something more
> specific to your context is involved.
> 
>> My notes: http://www.berklix.org/~jhs/pi/#images
> 
> I'll look at the notes separately, possibly not tonight.




===
Mark Millard
marklmi at yahoo.com