Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is broken for RPi2 v1.1 (so: armv7)

[Summary: it looks to be FreeBSD main's EFI loader that is
at issue for armv7 RPi2B v1.1 booting not working.]

On 2022-Oct-10, at 20:04, Mark Millard <marklmi@yahoo.com> wrote:

> I put:
> 
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> 
> on a microsd card via dd and tried to boot a RPi2 v1.1. it
> hung up after:
> 
> Using DTB provided by EFI at 0x7ef6000.
> Kernel entry at 0x36a00200...
> Kernel args: (null)
> 
> (A "-" might show in the next line.)
> 
> So I tried:
> 
> FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
> 
> on the microsd card instead. It worked just fine. (Thus the
> RPi2B v1.1 is not broken.)
> 
> I did this experiment because recent testing for other
> reasons of somewhat older main vintages that I'd built
> also showed such failures. This test shows official
> builds also have the problem.
> 
> I've no clue how long this issue has been around. It
> been a very long time since the RPi2B v1.1 had been
> powered on.
> 
> 
> Note: The arm-armv7-GENERICSD images include the RPi2B
> v1.1 related RPi* firmware and u-boot, in addition to
> an installed FreeBSD EFI loader and a kernel and a
> world. Historically it was supposed to just work for
> RPi2B v1.1's. 

I mounted the main [so: 14] media to /mnt and
copied /mnt/EFI/BOOT/bootarm.efi to
/boot/msdos/EFI/BOOT/bootarm.efi .

The result makes the 13.1-STABLE media fail in
the same sort of manor as 14-CURRENT did.

So I tried an experiment going in the other
direction: copying 13.1-STABLE's
EFI/BOOT/bootarm.efi into a main [so: 14]
context that had been failing to boot.
It then boots fine.

main's armv7 EFI/BOOT/bootarm.efi is broken, at
least for RPi2B v1.1 systems.

===
Mark Millard
marklmi at yahoo.com