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

On 2022-Oct-10, at 21:08, Warner Losh <imp@bsdimp.com> wrote:

> On Mon, Oct 10, 2022, 10:00 PM Mark Millard <marklmi@yahoo.com> wrote:
> [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.
> 
> Can you write a brief summary so I can recreate?

This is an independent report from the exchange
with Bob P. about his overall problems. This has
its own subject text. There is not much to this
specific report. Messages with other subjects
should be ignored for this issue. USB media is
not involved here: a microsd card is sufficient
to see the problem.

> And are you sure it's a booting issue and not a console issue?

No clue for your distinction. But, being serial console
based until ssh is possible for my context, I classify
serial-console-broken as a booting issue. (For example,
not being able to identify the DHCP address assigned
if it did make it that far.)

It may be that the snapshots need to be modified to deal
with EFI loader changes --instead of changes to the loader
needing to be made. I'm not trying to specify which.

> I can't make heads or tails of this whole thread. I need something simple, that's like 5 steps with version numbers.

The images listed in the above are the official snapshots.
I've no way to be more explicit than the file names of the
official snaphot images. The use of 20220930 (date) instead
of 20221007 for main's snapshot was an accident and I could
try the one with the more recent date if needed.

If you have RPi2B v1.1 (so: armv7) access, just try to boot:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img

via serial console usage, no video connection present. (I
did not try a video connection as that is not my type of
context.)

To make it work for that context, replace the EFI/BOOT/bootarm.efi
by the one from:

FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img

and then retry booting the result.

===
Mark Millard
marklmi at yahoo.com