Isn't the RPI2 v1.2 actually a bcm2837 rather than 2836, and therefore an aarch64 platform (cortex-a53 cpu) whereas the v1.1 is 32-bit arm (cortex-a7) ?

(In reply to andrew from comment #1)

The rpi2 V1.2 is a slower variation of the rpi3 more than it
is a variation of the rpi2 V1.1 . And, yes, cortex-a53 based,
not cortex-a7 based.

But the "standard" OS uses V1.2 as the aarch32 subset of
aarch64. It is not used as 64-bit overall. The same is
true of the rpi3.

So far FreeBSD has gone the aarch64 route only for the
rpi3 as I understand. That would suggest the same status
for rpi2 V1.2 as well.

Making the rpi2 v1.2 look to be basically compatible in
user space to rpi2 V1.1 would be a rather different
direction of development. I'm not so sure anyone is
intending to spend effort on such.

[The V1.2 vs. V1.1 naming makes all old references to
rpi2 ambiguous. If it is not qualified then it likely
is only a V1.1 context as a general rule, at least
outside it official OS distribution.]

(In reply to Mark Millard from comment #2)

Hmm. I should have noted:

RPi2 v1.n for n<2: Cortex-A7 (armv7).
RPi2 v1.2: Cortex-A53 (aarch64 with AArch32 support)
But . . .
The images referenced in the submittal are for armv6,
predating armv7 as well.

I will note that armv7-support boots a RPi2 v1.2
(aarch64) okay (serial console context):

# uname -apKU
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n261233-005cca8361a4: Thu Mar  2 11:16:04 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1400081 1400081

(one of the snaphot builds at the time) on:

CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080)

( an example download name that is more recent:
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230330-1fb7d2cf999e-261872.img.xz )

The boot media is an example that I just happen to have
around. Due to USB media issues, the u-boot context has a
usb_pgood_delay setting involved. This was a boot from-USB
test context with microsd card having only:

# mount -onoatime -tmsdosfs /dev/mmcsd0s1 /mnt
root@generic:~ # ls -Tld /mnt/*
-rwxr-xr-x  1 root  wheel  18693 Jan  6 11:16:16 2023 /mnt/COPYING.linux
-rwxr-xr-x  1 root  wheel   1594 Jan  6 11:16:16 2023 /mnt/LICENCE.broadcom
-rwxr-xr-x  1 root  wheel  52476 Jan  8 00:22:34 2023 /mnt/bootcode.bin
-rwxr-xr-x  1 root  wheel  52476 Jan  6 11:16:16 2023 /mnt/bootcode.bin.orig
-rwxr-xr-x  1 root  wheel      0 Apr 24 10:58:58 2022 /mnt/timeout

(The bootcode.bin had been patched to have more RPi* firmware
debug output on the serial console, per the standard instructions
for using sed to do so.)

# ls -Tld /boot/efi/*
drwxr-xr-x  1 root  wheel     4096 Mar  2 11:58:12 2023 /boot/efi/EFI
-rwxr-xr-x  1 root  wheel   105504 Mar  2 07:09:58 2023 /boot/efi/MLO
-rwxr-xr-x  1 root  wheel    26745 Mar  3 13:29:56 2021 /boot/efi/bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    52456 Mar  3 13:29:56 2021 /boot/efi/bootcode.bin
-rwxr-xr-x  1 root  wheel      117 Apr  2 22:27:10 2023 /boot/efi/config.txt
-rwxr-xr-x  1 root  wheel       89 Mar  2 07:17:40 2023 /boot/efi/config.txt.orig
drwxr-xr-x  1 root  wheel     8192 Mar  2 11:58:12 2023 /boot/efi/dtb
-rwxr-xr-x  1 root  wheel     7314 Mar  3 13:29:56 2021 /boot/efi/fixup.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 13:29:56 2021 /boot/efi/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 /boot/efi/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 /boot/efi/fixup_x.dat
drwxr-xr-x  1 root  wheel     4096 Mar  2 11:58:16 2023 /boot/efi/overlays
-rwxr-xr-x  1 root  wheel  2952960 Mar  3 13:29:56 2021 /boot/efi/start.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 13:29:56 2021 /boot/efi/start_cd.elf
-rwxr-xr-x  1 root  wheel  4794472 Mar  3 13:29:56 2021 /boot/efi/start_db.elf
-rwxr-xr-x  1 root  wheel  3704808 Mar  3 13:29:56 2021 /boot/efi/start_x.elf
-rwxr-xr-x  1 root  wheel   521916 Mar  2 07:17:24 2023 /boot/efi/u-boot.bin
-rwxr-xr-x  1 root  wheel   521956 Feb  6 08:56:36 2023 /boot/efi/u-boot.bin.2023.01.armv7
-rwxr-xr-x  1 root  wheel  1366352 Mar  2 07:09:58 2023 /boot/efi/u-boot.img

I do not have any armv6 boot media around, nor access to any RPi*'s
that are armv6. So at this point I've no direct evidence relative
to armv6 boot media.

I'll note that the only armv6 snapshots these days are the likes
of (recent example's download file name):

FreeBSD-14.0-CURRENT-arm-armv6-RPI-B-20230330-1fb7d2cf999e-261872.img.xz

which only mentions the older "RPI-B", not RPI2 . The original
submittal may have predated direct armv7 RPi* support in FreeBSD,
which may be why armv6 and RPI2 are both in the older names.

I'll also note that it has been proposed to start the process of
dropping armv6 support from future releases.

So this submittal may well be an example of "Overcome By Events"
or at least be headed that way.

(In reply to Mark Millard from comment #3)

I looked and

FreeBSD-14.0-CURRENT-arm-armv6-RPI-B-20230330-1fb7d2cf999e-261872.img.xz

does not contain bcm2709-rpi-2-b.dtb (the RPi2 v1.1 / armv7 dtb).
So it will not boot a RPi2 v1.1 or later just because of the RPi*
firmware not finding a matching .dtb for the RPi* involved: so it
stops long before anything from FreeBSD gets involved. What the
media with the .img ends up having is just:

# ls -Tld /mnt/*
drwxr-xr-x  1 root  wheel     4096 Mar 30 07:14:16 2023 /mnt/EFI
-rwxr-xr-x  1 root  wheel    25870 Mar  3 05:29:56 2021 /mnt/bcm2708-rpi-b-plus.dtb
-rwxr-xr-x  1 root  wheel    25607 Mar  3 05:29:56 2021 /mnt/bcm2708-rpi-b.dtb
-rwxr-xr-x  1 root  wheel    25529 Mar  3 05:29:56 2021 /mnt/bcm2708-rpi-cm.dtb
-rwxr-xr-x  1 root  wheel    26545 Mar  3 05:29:56 2021 /mnt/bcm2708-rpi-zero-w.dtb
-rwxr-xr-x  1 root  wheel    52456 Mar  3 05:29:56 2021 /mnt/bootcode.bin
-rwxr-xr-x  1 root  wheel       89 Mar 30 02:34:12 2023 /mnt/config.txt
drwxr-xr-x  1 root  wheel     4096 Mar 30 07:14:16 2023 /mnt/dtb
-rwxr-xr-x  1 root  wheel     7314 Mar  3 05:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 05:29:56 2021 /mnt/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 05:29:56 2021 /mnt/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 05:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x  1 root  wheel     4096 Mar 30 07:14:18 2023 /mnt/overlays
-rwxr-xr-x  1 root  wheel  2952960 Mar  3 05:29:56 2021 /mnt/start.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 05:29:56 2021 /mnt/start_cd.elf
-rwxr-xr-x  1 root  wheel  4794472 Mar  3 05:29:56 2021 /mnt/start_db.elf
-rwxr-xr-x  1 root  wheel  3704808 Mar  3 05:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x  1 root  wheel   532460 Mar 30 02:24:24 2023 /mnt/u-boot.bin

where the bcm2708-rpi*.dtb files indicates the armv6 status for what
FreeBSD choose to include. The u-boot-bin would also need to be armv6
compatibile for this to work. (I've no armv6 hardware context to
test.) (FYI: by contrast, bcm2709-rpi* indicates an armv7 status).

bcm2709-rpi-2-b.dtb could be added, but then RPi2 v1.1+ would boot
as armv7 in FreeBSD, based on what bcm2709-rpi-2-b.dtb describes
and FreeBSD having armv7 support.

It seems likely that the older *-arm-armv6-RPI2-* images had
bcm2709-rpi-2-b.dtb present. That might be why RPI2 is explict in
the older image name, not just indicating armv6.

So, from what I can tell, more evidence for "Overcome By Events".

I'm able to boot the ARM64 "pi" image for 14.0 on a Pi 2 B v1.2 without any issues.

Maybe this can be marked as overcome by events?

I think documentation could maybe be updated to reflect this as well, if others have the same luck.