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

On 2022-Oct-11, at 19:55, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Oct-11, at 12:10, Warner Losh <imp@bsdimp.com> wrote:
> 
>> On Tue, Oct 11, 2022 at 1:03 PM Warner Losh <imp@bsdimp.com> wrote:
>>> 
>>> 
>>> On Tue, Oct 11, 2022 at 12:50 PM Mark Millard <marklmi@yahoo.com> wrote:
>>> . . .
>>> 
>>> For:
>>> 
>>> boot-2022-09-16-15-45-b44869cba1b3-good
>>> boot-2022-09-16-18-02-dd2b9c296776-bad
>>> 
>>> there are no armv7 artifacts available between.
>>> 
>>> The range is:
>>> 
>>>        A) • git: b44869cba1b3 - main - sound: add patch for Lenovo Legion 5 Intel Nuno Teixeira 
>>>        B) • git: a705c72f2142 - main - stand: use archsw.arch_copyin instead of i386_copyin Warner Losh 
>>>        C) • git: 4c670b53a000 - main - stand: use archsw.arch_copyin instead of direct call Warner Losh 
>>>        D) • git: 8b19d28d68a3 - main - stand: Create MOD_ALIGN macro and use it everywhere Warner Losh 
>>>        E) • git: bca9c87b6104 - main - stand: Create common/modinfo.h Warner Losh 
>>>        F) • git: 5d1531d9d4e7 - main - stand: Move md_copymodules into modinfo.c and reduce copies Warner Losh 
>>>        G) • git: 2e6ed47a4609 - main - stand: Move MOD_xxx macros from modinfo.h to .c Warner Losh 
>>>        H) • git: fc352701ff3a - main - stand: collapse all copies of *copyenv into md_copyenv Warner Losh 
>>>        • git: e895ab3fbdc1 - main - stand: Remove dead store to bi_kernelname Warner Losh 
>>>        • git: d43bcf62a218 - main - stand: Stop support booting 4.x and earlier kernels Warner Losh 
>>>        • git: 59b1d074280d - main - i386: Mark the obsolete fields in bootinfo with _was_ Warner Losh 
>>>        • git: 4134f677eb39 - main - i386: Make boot loader smaller by reducing size of bootinfo Warner Losh 
>>>        • git: 9758dd3de1cd - main - stand: Allocate bootinfo rather than have it be static Warner Losh 
>>>        • git: c0ecae78abbe - main - stand/elf: Only support swapping headers on powerpc. Warner Losh 
>>>        • git: dd2b9c296776 - main - stand: fix mismerge Warner Losh
>>> 
>> Yea, I did a bunch of refactoring. I'm surprised that this produced a change at all. Would be nice to
>> know which one of these caused the problems.
> 
> 5d1531d9d4e7 has the stand/common/metadata.c "align"
> removal that the later dd2b9c296776 fixes as the
> "mismerge". So it appears that most of the stages
> would not build without adjustment for that.
> 
> So presume I've made the adjustment for any such
> such cases below.
> 
> H) fc352701ff3a Bad
> D) 8b19d28d68a3 Good
> F) 5d1531d9d4e7 Bad
> E) bca9c87b6104 Good
> 
> So the good -> bad back-to-back sequence pair is:
> 
> git: bca9c87b6104 - main - stand: Create common/modinfo.h Warner Los
> git: 5d1531d9d4e7 - main - stand: Move md_copymodules into modinfo.c and reduce copies Warner Losh
> 
> 
> Note: I cross build armv7 via aarch64 normally.
> There is no "buildstand" analogous to buildworld
> or buildkernel that takes TARGET and TARGET_ARCH
> for cross builds. Thus I ended up with a full
> buildworld to establish a context for the cross
> builds.
> 

I got another oddity to add to the evidence,
although it might just be a separate issue.

First off some context: With the additions to
the microsd card:

/boot/efi/bcm2710-rpi-2-b.dtb
/boot/efi/bcm2710-rpi-3-b-plus.dtb
/boot/efi/bcm2710-rpi-3-b.dtb
/boot/efi/bcm2710-rpi-cm3.dtb

I can have armv7 13.1-STABLE FreeBSD boot:

RPi2B v1.1 (The official support targets this.)
RPi2B v1.2 (not tested but I could)
RPi3B+     (no access to such)
RPi3B      (tested)
Computer Module 3 (no access to such)

(I recently sent out notes out that are for mostly USB
booting to match more closely Bob P.'s context. This
has some more involved to span the range and some
specifics of dealing with oddities of the media I have
access to show up in order for me to demonstrate
operation.)

Part of the point of 13.1-STABLE here is avoiding all
the recent EFI loader changes, not just one block of
them.

But for main [so: 14] and the same bca9c87b6104 based EFI
loader that I reported as working on the RPi2B v1.1, I get
differing behavior between:

RPi2B v1.1 (boots with serial console & HDMI output throughout)
vs.
RPi3B      (serial output stops and, when HDMO is connected,
            HDMI output keeps going)

For the RPi3B, the last serial console line output is:

Kernel args: (null)

By contrast, for RPi2B v1.1 with both the serial console and
the HDMI connected, both get console output, reaching the
login prompt. (I've not certified every line is present
on both. There could be differences for all I know.)

So, in this context, the RPi3B seems to hit the console
handling type of issue that you were originally expecting.

I originally looked into this in case the results meant
that you could use a bcm2710 based RPi* instead of a
bcm2709 based one for investigating the armv7-style-boot
with 5d1531d9d4e7 and later EFI loader problem(s), giving
you more options.

===
Mark Millard
marklmi at yahoo.com