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

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.

	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*

	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