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 22:50, Mark Millard <[email protected]> wrote:

> On 2022-Oct-10, at 21:08, Warner Losh <[email protected]> wrote:
> 
>> On Mon, Oct 10, 2022, 10:00 PM Mark Millard <[email protected]> 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 <[email protected]> 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.

I've tried the snapshot:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20221007-b05b1ecbef0-258483.img

and got the same boot failure when it is what is on the
microsd card (no EFI loader replacement).

I got access to a display and HDMI cable and tried booting
with it connected. The last text it displays matches the
last text on the serial console:

Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33800200...
Kernel args: (null)
-

(ignoring, possibly, the "-").


===
Mark Millard
marklmi at yahoo.com