Date: Tue, 11 Oct 2022 07:17:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is broken for RPi2 v1.1 (so: armv7) Message-ID: <CANCZdfoU2Ln2vqymT66Yu6ZdxSrZLAx1%2BA_hstLYSrzBmduHBw@mail.gmail.com> In-Reply-To: <FC871551-7C49-4751-8763-2E8F82C1480A@yahoo.com> References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com> <D9B791B7-106A-402E-AD8C-F811EB315560@yahoo.com> <CANCZdfoJ=E=ef86PRaYsvgXWLAu=AdbN%2B_kiv0vPhKVksqPY%2Bg@mail.gmail.com> <FC871551-7C49-4751-8763-2E8F82C1480A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000005e164505eac21a65
Content-Type: text/plain; charset="UTF-8"
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
--0000000000005e164505eac21a65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 10, 2022 at 11:50 PM Mark=
Millard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-=
Oct-10, at 21:08, Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=
=3D"_blank">imp@bsdimp.com</a>> wrote:<br>
<br>
> On Mon, Oct 10, 2022, 10:00 PM Mark Millard <<a href=3D"mailto:mark=
lmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> [Summary: it looks to be FreeBSD main's EFI loader that is<br>
> at issue for armv7 RPi2B v1.1 booting not working.]<br>
> <br>
> On 2022-Oct-10, at 20:04, Mark Millard <<a href=3D"mailto:marklmi@y=
ahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> <br>
> > I put:<br>
> > <br>
> > FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258=
315.img<br>
> > <br>
> > on a microsd card via dd and tried to boot a RPi2 v1.1. it<br>
> > hung up after:<br>
> > <br>
> > Using DTB provided by EFI at 0x7ef6000.<br>
> > Kernel entry at 0x36a00200...<br>
> > Kernel args: (null)<br>
> > <br>
> > (A "-" might show in the next line.)<br>
> > <br>
> > So I tried:<br>
> > <br>
> > FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-2526=
53.img<br>
> > <br>
> > on the microsd card instead. It worked just fine. (Thus the<br>
> > RPi2B v1.1 is not broken.)<br>
> > <br>
> > I did this experiment because recent testing for other<br>
> > reasons of somewhat older main vintages that I'd built<br>
> > also showed such failures. This test shows official<br>
> > builds also have the problem.<br>
> > <br>
> > I've no clue how long this issue has been around. It<br>
> > been a very long time since the RPi2B v1.1 had been<br>
> > powered on.<br>
> > <br>
> > <br>
> > Note: The arm-armv7-GENERICSD images include the RPi2B<br>
> > v1.1 related RPi* firmware and u-boot, in addition to<br>
> > an installed FreeBSD EFI loader and a kernel and a<br>
> > world. Historically it was supposed to just work for<br>
> > RPi2B v1.1's. <br>
> <br>
> I mounted the main [so: 14] media to /mnt and<br>
> copied /mnt/EFI/BOOT/bootarm.efi to<br>
> /boot/msdos/EFI/BOOT/bootarm.efi .<br>
> <br>
> The result makes the 13.1-STABLE media fail in<br>
> the same sort of manor as 14-CURRENT did.<br>
> <br>
> So I tried an experiment going in the other<br>
> direction: copying 13.1-STABLE's<br>
> EFI/BOOT/bootarm.efi into a main [so: 14]<br>
> context that had been failing to boot.<br>
> It then boots fine.<br>
> <br>
> main's armv7 EFI/BOOT/bootarm.efi is broken, at<br>
> least for RPi2B v1.1 systems.<br>
> <br>
> Can you write a brief summary so I can recreate?<br>
<br>
This is an independent report from the exchange<br>
with Bob P. about his overall problems. This has<br>
its own subject text. There is not much to this<br>
specific report. Messages with other subjects<br>
should be ignored for this issue. USB media is<br>
not involved here: a microsd card is sufficient<br>
to see the problem.<br>
<br>
> And are you sure it's a booting issue and not a console issue?<br>
<br>
No clue for your distinction. But, being serial console<br>
based until ssh is possible for my context, I classify<br>
serial-console-broken as a booting issue. (For example,<br>
not being able to identify the DHCP address assigned<br>
if it did make it that far.)<br></blockquote><div><br></div><div>So it'=
s not a booting issue (where the loader can't find the disk,</div><div>=
can't load the kernel or loads it such that it hangs), but a default</d=
iv><div>console issue. That's a lot easier for me to help solve.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It may be that the snapshots need to be modified to deal<br>
with EFI loader channges --instead of changes to the loader<br>
needing to be made. I'm not trying to specify which.<br></blockquote><d=
iv><br></div><div>Loader should likely change. There was what may have been=
</div><div>an unwise change to the default console a while ago and it's=
</div><div>taken this long to see the problem.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
> I can't make heads or tails of this whole thread. I need something=
simple, that's like 5 steps with version numbers.<br>
<br>
The images listed in the above are the official snapshots.<br>
I've no way to be more explicit than the file names of the<br>
official snaphot images. The use of 20220930 (date) instead<br>
of 20221007 for main's snapshot was an accident and I could<br>
try the one with the more recent date if needed.<br></blockquote><div><br><=
/div><div>The change was made in late August that I'm thinking of, so i=
f you could find a</div><div>snapshot from early August July that would be =
a useful data point:</div><div><br></div><div>commit df065f699f1ff819bb9607=
c44a6754275ab335ed<br>Author: Warner Losh <imp@FreeBSD.org><br>Date: =
=C2=A0 Fri Aug 26 15:46:33 2022 -0600<br><br>=C2=A0 =C2=A0 stand: More sens=
ible defaults when ConOut is missing<br></div><div><br></div><div>I think t=
his should be backed out and we should use a different hueristic</div><div>=
when we don't know.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">If you have RPi2B v1.1 (so: armv7) access, just try to b=
oot:<br>
<br>
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img<br=
>
<br>
via serial console usage, no video connection present. (I<br>
did not try a video connection as that is not my type of<br>
context.)<br></blockquote><div><br></div><div>I don't know if I can fin=
d that... I bought one or three years ago, so there's a good</div><div>=
chance... if it isn't being my name server...=C2=A0 I'll see if I c=
an recreate it in qemu</div><div>as well, since I think it emulates RPi the=
se days. I need armv7 for the stand</div><div>test suite I'm writing...=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To make it work for that context, replace the EFI/BOOT/bootarm.efi<br>
by the one from:<br>
<br>
FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img<br>
<br>
and then retry booting the result.<br></blockquote><div><br></div><div>OK. =
That's a fairly clear set of instructions.=C2=A0 I'll try to work t=
hat into my</div><div>schedule.</div><div><br></div><div>Warner</div></div>=
</div>
--0000000000005e164505eac21a65--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoU2Ln2vqymT66Yu6ZdxSrZLAx1%2BA_hstLYSrzBmduHBw>