From nobody Tue Oct 11 13:17:39 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MmxD04jkdz4fjH4 for ; Tue, 11 Oct 2022 13:17:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmxD00CZYz3fyh for ; Tue, 11 Oct 2022 13:17:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x52b.google.com with SMTP id s2so20109729edd.2 for ; Tue, 11 Oct 2022 06:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vT2IZgNJFG0p1QgZ3Xi6y0P3jPy5yUUiCz6bkawUAI0=; b=rDaUwXIPuKowxJ+IbnVlGDUKTPhq9ZeMmT9lVHU/M49eUsvRYj2kxCyA76cESABrJ/ kY226lHFKNfySGCNX4FNbh8OsrF/IJPQrirL3Q1v6jcwV/8xsvmcIbBl/g1ml5NkV6Wg wQ2QgcWLU20UiM90l8646BufRBbSQ9a/lAsvOH46uhfjGgrTbHyJyB0KD109j1iXVbdF ehPvA6bFh3MW9MEmyxHHaexNMhRIVCrpZVQYKt1t1+7ewr6oZjvXRoB0u6YoneJhR4mv Krob2ZOPxDfRZLLuoX0/O9iKw97j0NiJ+45tkpJeT0xMZlwOWhqT/bfb3UoZCNnQwzu/ 5y1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vT2IZgNJFG0p1QgZ3Xi6y0P3jPy5yUUiCz6bkawUAI0=; b=LXxAXGuhQdI5GWU+wYE6aNmbkdrf3EJSvOPzXc7HZF7WmlGdtYFKjWYQyEZuiQZx4d aKXBUfGUggyvkMJEjNEIZyM4ifcDzxr0Noy+D9gswjiDkMqqCnkiEqz6iROZC3EIsRhM yIHfUvrWOojfxKpl1LvndPAiCwtHaalT54EQrWv1hmNRBZwxeamoY9AzI7p+6hgprK1d Kr6nzEEswxQ+5/398SDv7ezjqwLUzbLiC8QTbwnTxcpKlFzy00nWSJxibHE++WISiAaq i94s7Xdn5GprQ0ZHUEF46A54bIFHE5V38DSKLd5j7DiffW2jOpFiY/hPqOvcs5cO6pDR aUGw== X-Gm-Message-State: ACrzQf0lyQLTStrcWTa1XxEvTbatJmTEdIM5GOEFXQP9dagFs1lt6J2o 2KPVx3hjCuSroynfxYfcdpCDso3lVb85pRSFAeolIw== X-Google-Smtp-Source: AMsMyM6+G1KupufOZUZ5xUVJh72PVdqcRNubxiBq24cxAAGLtUnp+CyJCRIeYjL/Klh5R4F9JEa/QgTjEg3LDa9Y6yg= X-Received: by 2002:a05:6402:1d86:b0:457:e84:f0e with SMTP id dk6-20020a0564021d8600b004570e840f0emr22579714edb.241.1665494270476; Tue, 11 Oct 2022 06:17:50 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com> In-Reply-To: From: Warner Losh Date: Tue, 11 Oct 2022 07:17:39 -0600 Message-ID: Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is broken for RPi2 v1.1 (so: armv7) To: Mark Millard Cc: freebsd-arm , bob prohaska Content-Type: multipart/alternative; boundary="0000000000005e164505eac21a65" X-Rspamd-Queue-Id: 4MmxD00CZYz3fyh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=rDaUwXIP; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52b) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000005e164505eac21a65 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 10, 2022 at 11:50 PM Mark Millard wrote: > On 2022-Oct-10, at 21:08, Warner Losh wrote: > > > On Mon, Oct 10, 2022, 10:00 PM Mark Millard 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 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 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


=
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-258= 315.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-2526= 53.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.
<= div>=C2=A0
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.
=C2=A0
> 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.

<= /div>
The change was made in late August that I'm thinking of, so i= f you could find a
snapshot from early August July that would be = a useful data point:

commit df065f699f1ff819bb9607= c44a6754275ab335ed
Author: Warner Losh <imp@FreeBSD.org>
Date: = =C2=A0 Fri Aug 26 15:46:33 2022 -0600

=C2=A0 =C2=A0 stand: More sens= ible defaults when ConOut is missing

I think t= his 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 b= oot:

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 fin= d that... I bought one or three years ago, so there's a good
= chance... if it isn't being my name server...=C2=A0 I'll see if I c= an recreate it in qemu
as well, since I think it emulates RPi the= se days. I need armv7 for the stand
test suite I'm writing...=
=C2=A0
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.=C2=A0 I'll try to work t= hat into my
schedule.

Warner
=
--0000000000005e164505eac21a65--