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

On Mon, Oct 10, 2022 at 11:50 PM Mark Millard <marklmi@yahoo.com> wrote:

> 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.)
>

So it's not a booting issue (where the loader can't find the disk,
can't load the kernel or loads it such that it hangs), but a default
console issue. That's a lot easier for me to help solve.


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

Loader should likely change. There was what may have been
an unwise change to the default console a while ago and it's
taken this long to see the problem.


> > 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.
>

The change was made in late August that I'm thinking of, so if you could
find a
snapshot from early August July that would be a useful data point:

commit df065f699f1ff819bb9607c44a6754275ab335ed
Author: Warner Losh <imp@FreeBSD.org>
Date:   Fri Aug 26 15:46:33 2022 -0600

    stand: More sensible defaults when ConOut is missing

I think this should be backed out and we should use a different hueristic
when we don't know.

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.)
>

I don't know if I can find that... I bought one or three years ago, so
there's a good
chance... if it isn't being my name server...  I'll see if I can recreate
it in qemu
as well, since I think it emulates RPi these days. I need armv7 for the
stand
test suite I'm writing...


> 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.
>

OK. That's a fairly clear set of instructions.  I'll try to work that into
my
schedule.

Warner