From nobody Tue Oct 25 04:52:51 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 4MxKM63bCSz4gdCL for ; Tue, 25 Oct 2022 04:53:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 4MxKM5350mz3kcX for ; Tue, 25 Oct 2022 04:53:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x62f.google.com with SMTP id b2so9689931eja.6 for ; Mon, 24 Oct 2022 21:53:05 -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=HXLvYBQDUxPWYAmZIQWGTR8xy0p+sBx9wGXvM08donk=; b=QeKPORm5vIRyV14J5KmPyVfP4rgiDQ2Fgp7B3X6+GaqSC1VFs7BFVyKnYugHCQUPC2 JzQEqDNg+Dn2LN8cQ5R47t50P3UNXuPQrBI587XFjaAHQDoYLPYIhDewxTSacGcX7T7z gpYh622oKhtNzCTp9/7+ROfIOFeQ+7XIiyfnk1qC/29572y8Ceqs51J+YC4qhXjCamny nllE7Fa9/Sr5XuKlTqtb1FoJtDqYLf7q3t3HwkWxxsqLJ7shX/pfO3EGY2EfPWP0M6QG zBdIKgQGHletikwXpLjUxmI1xmC9/LOOGB2YPpdVMj0jtU4JQuSdGKrqQcu6EiEZpk5L X8JA== 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=HXLvYBQDUxPWYAmZIQWGTR8xy0p+sBx9wGXvM08donk=; b=3oUhLvcg+vBfmVuurOr775saLHiXEmTp7xs/tWEBV9I+QXOHew5PTBNFp+orAao6vP Nkl/YtP1qEk+NO6F+0lOMl0k9vZ8HT6/3/DQl4uWGVTpTCP2qjt7LJTXzBauKYSRf8Nb D/0VWPwYZHzz6R+HaLOjCBDrOSbOGIWX5n00bp4X1Q2QYz1SID2yDcXEZIfz74c1AasM XQqE8CCd+9Zi/e8LNyVROr4RyXgTeTjmn4P3DDndeW+hlv2bC5+EVZmDgEHTPMpajyLm IIj2M7uPDEAiXEZQJDJiRmW4LyElVhUU/JoQMsaOQ1FSoxwrlPMbigUpn9PmaklepbD7 sPUw== X-Gm-Message-State: ACrzQf2Lwy20h04rKubh+bo7SbJCcV2cjRHTGVrQv6LHXB63D7jkPJRk IUscpGUuHHx7bp38vkrMcWm1OTxGC48MVPLYLTX2nQ== X-Google-Smtp-Source: AMsMyM7E+P+Wa8dJpVmwIIzLxVIlXiMArbcz5bEYP7NnbwMr84UoILkDefii8qwgSDiIuocR3Zz/p7+g8JrjhPpvhG4= X-Received: by 2002:a17:907:d02:b0:7a3:de36:b67 with SMTP id gn2-20020a1709070d0200b007a3de360b67mr10705814ejc.451.1666673582972; Mon, 24 Oct 2022 21:53:02 -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: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com> <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com> <20221021175142.GA62386@www.zefox.net> <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com> <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com> <20221024174930.GA79381@www.zefox.net> <20221025005012.GA80394@www.zefox.net> <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com> In-Reply-To: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com> From: Warner Losh Date: Mon, 24 Oct 2022 22:52:51 -0600 Message-ID: Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it To: Mark Millard Cc: bob prohaska , "Klaus K??chemann" , freebsd-arm Content-Type: multipart/alternative; boundary="000000000000deb6c305ebd4aece" X-Rspamd-Queue-Id: 4MxKM5350mz3kcX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=QeKPORm5; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-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]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; FREEMAIL_CC(0.00)[www.zefox.net,googlemail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --000000000000deb6c305ebd4aece Content-Type: text/plain; charset="UTF-8" On Mon, Oct 24, 2022 at 9:32 PM Mark Millard wrote: > On 2022-Oct-24, at 17:50, bob prohaska wrote: > > > On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote: > >> > >> bootcode.bin is only likely to help stages before > >> u-boot.bin starts. If it makes to to u-boot.bin > >> starting, bootcode.bin is then likely irrelevant > >> from then on. > >> > >> In fact bootcoce.bin is what loads the start*.elf > > Typo fix: bootcode.bin > > >> that is used. If the start*.elf starts, bootcode.bin > >> is likely irrelevant past that point. > >> > > I've put the console output at > > http://www.zefox.net/~fbsd/rpi2/20221024/boot_console > > in case it's of interest. > > It was a RPi2B v1.1 (Cortex-A7 form of armv7). > > It was a U-Boot 2022.04 based boot sequence for > the U-Boot stage. > > swapon: /dev/sdda0s2b: No such file or directory looks > like us has an incorrect "sd" between "/" and "da0s2b". > > I've not seen/noticed the following before: > > QUOTE > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg > Soft Float compatibility ldconfig path: > ldconfig: illegal option -- o > usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file > ...] > END QUOTE > > But, to my knowledge, "Soft Float" is not in use any more > (by default, anyway). It might be that something is left > over from long ago? Looking, I see: > I was sure that all attempts to use it in FreeBSD 12+ had been removed.... > QUOTE > author Warner Losh 2022-01-07 05:34:18 +0000 > committer Warner Losh 2022-01-07 05:34:18 +0000 > commit d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch) > tree 14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e /libexec/rc/rc.d/ldconfig > parent b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff) > download src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.tar.gz > src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip > > libsoft: Remove runtime ldconfig support for libsoft > > Remove the runtime support for running ldconfig at boot to cache lists > of libsoft libbraries. > END QUOTE > > ( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .) > > Your /etc/rc.d/ldconfig script seems to have not been updated > by use of etcupdate or mergemaster or other such. (How much > else is also out of date? How much of what you have for /etc/ > and the like goes back to 2022-Jan-07 or before?) > Yea... that seems likely... Can you confirm that I've not messed up a merge somewhere? > > There are a surprising number > > of what look like complaints/errors, but it boots anyway. > > > >> > >>> The interest I expressed in EDK2 appears to have been misguided, > >>> or at least premature. I was hoping it might be a more tractable > >>> replacement for u-boot, but it's equally inscrutable to an amateur. > >> > >> > >> Was this based on mina ports before vs. after: > > Another wonderful typo of mine: "mina". > > >> QUOTE > >> author Mark Millard 2022-10-21 > 21:47:14 +0000 > >> committer Lorenzo Salvadore > 2022-10-21 22:00:03 +0000 > >> > > > > After. Before it failed in the expected way. After, it succeeded, but > > built edk2 for macchiatobin that wasn't useful. I couldn't figure out > > how to make poudriere attempt to build the needed rpi3 flavor > > (The FLAVORS material below is more for providing > background in building flavored ports than for EDK2 > specifically, but using EDK2 as the example . . .) > > The sysutils/edk2/Makefile has: > > FLAVORS= macchiatobin fvp rpi3 rpi4 xen_x64 bhyve qemu_x64 qemu_i386 > > Being listed first, macchiatobin is the default flavor. To specify > a flavor explicitly on the poudriere bulk command, use notation > like one or more of the following on the command line: > > sysutils/edk2@macchiatobin > sysutils/edk2@fvp > sysutils/edk2@rpi3 > sysutils/edk2@rpi4 > > So the last 2 of those 4 are the ones that fit your > context. (The later ones in the FLAVORS list have: > ONLY_FOR_ARCHS=amd64 .) > > Other than flavors handling . . . > > I've commented before that I'm not aware of an > armv7 EDK2. So no coverage of an RPi2 v1.1 as > far as I know. ( Also known via any of its > dtb names, such as: bcm2709-rpi-2-b.dtb . > bcm2710-rpi-2-b.dtb is the v1.2 aarch64 > variant.) > Yea, we get our UEFI support via u-boot there... Warner > The RPi3 EDK2 only supplies the RPi* firmware that > it gets via curl when the official RPi3 pftf EDK2 > ( https://github.com/pftf/RPi3 ) related builds are done: > > - name: Download Raspberry Pi support files > run: | > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/start.elf > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b.dtb > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b-plus.dtb > curl -O -L > https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-cm3.dtb > > (FreeBSD's port does not deal with such things at all.) > > So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3 > EDK2 would be well behaved with an appropriate vintage > bcm2710-rpi-2-b.dtb added or not. I've never tried > such. > > I forgot to mention that the offical RPI4 pftf EDK2 > ( https://github.com/pftf/RPi4 ) related build has 2 > patches to EDK2: > > - name: Patch EDK2 repositories > run: | > patch --binary -d edk2 -p1 -i > ../0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch > patch --binary -d edk2-platforms -p1 -i > ../0002-Check-for-Boot-Discovery-Policy-change.patch > > These would not be in the FreeBSD port's build. > > FYI, for the RPi4 EDK2: > > - name: Download Raspberry Pi support files > run: | > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ > env.START_ELF_VERSION }}/boot/fixup4.dat > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ > env.START_ELF_VERSION }}/boot/start4.elf > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION > }}/boot/bcm2711-rpi-4-b.dtb > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION > }}/boot/bcm2711-rpi-cm4.dtb > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION > }}/boot/bcm2711-rpi-400.dtb > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION > }}/boot/overlays/miniuart-bt.dtbo > curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION > }}/boot/overlays/upstream-pi4.dtbo > mkdir overlays > mv *.dtbo overlays > > (I add and use disable-bt.stbo . They do mention its use in > some instructions someplace.) > > > and didn't > > find a flavor for rpi2. This was on a Pi4 running -current. > > I supplied notes about RPi2B's earlier, above. > > > It's unclear to me if edk2 offers any advantage over u-boot, at least > > when u-boot works. > > I only suggested EDK2 because U-Boot was not working > well and there might be a chance that EDK2 might work > better for for that stage in one or more of your > detailed contexts. (No claim that this would improve > FreeBSD kernel handling of any RPi*/bridge/drive > combinations --or the earlier RPi* firmware stage.) > > If it does not work better for any, I'd suggeste avoiding > being outside the somewhat supported FreeBSD RPi* context: > avoid EDK2. > > (I use both styles of booting, but I'm odd.) > > I'll note that the main ports has updated U-Boot's > from 2022.04 to 2022.10 . No clue if you might see > behavioral changes for the U-Boot stage if you > update. > > Also, Warner L. has checked in a fix for main FreeBSD's > EFI loader build ( in stand/efi/ ) for armv7(/armv6). > The next snapshot for armv7 main [so: 14] should have > it. > > > I think HPS's changes to usb probably did help, > > Good. > > > but > > won't know for a while yet given the erratic nature of the troubles. > > Yep. > > > === > Mark Millard > marklmi at yahoo.com > > > --000000000000deb6c305ebd4aece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 24, 2022 at 9:32 PM Mark = Millard <marklmi@yahoo.com> = wrote:
On 2022-O= ct-24, at 17:50, bob prohaska <fbsd@www.zefox.net> wrote:

> On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:
>>
>> bootcode.bin is only likely to help stages before
>> u-boot.bin starts. If it makes to to u-boot.bin
>> starting, bootcode.bin is then likely irrelevant
>> from then on.
>>
>> In fact bootcoce.bin is what loads the start*.elf

Typo fix: bootcode.bin

>> that is used. If the start*.elf starts, bootcode.bin
>> is likely irrelevant past that point.
>>
> I've put the console output at
> http://www.zefox.net/~fbsd/rpi2/20221024/= boot_console
> in case it's of interest.

It was a RPi2B v1.1 (Cortex-A7 form of armv7).

It was a U-Boot 2022.04 based boot sequence for
the U-Boot stage.

swapon: /dev/sdda0s2b: No such file or directory looks
like us has an incorrect "sd" between "/" and "da0= s2b".

I've not seen/noticed the following before:

QUOTE
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat/pkg /usr/local/lib/compat/pkg
Soft Float compatibility ldconfig path:
ldconfig: illegal option -- o
usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file ...= ]
END QUOTE

But, to my knowledge, "Soft Float" is not in use any more
(by default, anyway). It might be that something is left
over from long ago? Looking, I see:

I w= as sure that all attempts to use it in FreeBSD 12+ had been removed....
=C2=A0
QUOTE
author=C2=A0 Warner Losh <imp@FreeBSD.org>=C2=A0 =C2=A02022-01-07 05:= 34:18 +0000
committer=C2=A0 =C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>=C2= =A0 =C2=A02022-01-07 05:34:18 +0000
commit=C2=A0 d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)
tree=C2=A0 =C2=A0 14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e /libexec/rc/rc.d= /ldconfig
parent=C2=A0 b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)
download=C2=A0 =C2=A0 =C2=A0 =C2=A0 src-d418bc27e601ec6bba0506d0efb62eca5ed= a5ab8.tar.gz
src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip

libsoft: Remove runtime ldconfig support for libsoft

Remove the runtime support for running ldconfig at boot to cache lists
of libsoft libbraries.
END QUOTE

( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .)

Your /etc/rc.d/ldconfig script seems to have not been updated
by use of etcupdate or mergemaster or other such. (How much
else is also out of date? How much of what you have for /etc/
and the like goes back to 2022-Jan-07 or before?)

=
Yea... that seems likely... Can you confirm that I've not me= ssed up
a merge somewhere?
=C2=A0
> There are a surprising number
> of what look like complaints/errors, but it boots anyway.
>
>>
>>> The interest I expressed in EDK2 appears to have been misguide= d,
>>> or at least premature. I was hoping it might be a more tractab= le
>>> replacement for u-boot, but it's equally inscrutable to an= amateur.
>>
>>
>> Was this based on mina ports before vs. after:

Another wonderful typo of mine: "mina".

>> QUOTE
>> author=C2=A0 =C2=A0 =C2=A0 =C2=A0Mark Millard <marklmi26-fbsd@yahoo.com&= gt; 2022-10-21 21:47:14 +0000
>> committer=C2=A0 =C2=A0 Lorenzo Salvadore <salvadore@FreeBSD.org= >=C2=A0 =C2=A0 =C2=A0 =C2=A02022-10-21 22:00:03 +0000
>>
>
> After. Before it failed in the expected way. After, it succeeded, but<= br> > built edk2 for macchiatobin that wasn't useful. I couldn't fig= ure out
> how to make poudriere attempt to build the needed rpi3 flavor

(The FLAVORS material below is more for providing
background in building flavored ports than for EDK2
specifically, but using EDK2 as the example . . .)

The sysutils/edk2/Makefile has:

FLAVORS=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 macchiatobin fvp rpi3 rpi4 xen_x64 bh= yve qemu_x64 qemu_i386

Being listed first, macchiatobin is the default flavor. To specify
a flavor explicitly on the poudriere bulk command, use notation
like one or more of the following on the command line:

sysutils/edk2@macchiatobin
sysutils/edk2@fvp
sysutils/edk2@rpi3
sysutils/edk2@rpi4

So the last 2 of those 4 are the ones that fit your
context. (The later ones in the FLAVORS list have:
ONLY_FOR_ARCHS=3Damd64 .)

Other than flavors handling . . .

I've commented before that I'm not aware of an
armv7 EDK2. So no coverage of an RPi2 v1.1 as
far as I know. ( Also known via any of its
dtb names, such as: bcm2709-rpi-2-b.dtb .
bcm2710-rpi-2-b.dtb is the v1.2 aarch64
variant.)

Yea, we get our UEFI support = via u-boot there...

Warner

=C2=A0
The RPi3 EDK2 only supplies the RPi* firmware that
it gets via curl when the official RPi3 pftf EDK2
( https://github.com/pftf/RPi3 ) related builds are done:

=C2=A0 =C2=A0 - name: Download Raspberry Pi support files
=C2=A0 =C2=A0 =C2=A0 run: |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/start.elf =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bcm27= 10-rpi-3-b.dtb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/= bcm2710-rpi-3-b-plus.dtb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bcm27= 10-rpi-cm3.dtb

(FreeBSD's port does not deal with such things at all.)

So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3
EDK2 would be well behaved with an appropriate vintage
bcm2710-rpi-2-b.dtb added or not. I've never tried
such.

I forgot to mention that the offical RPI4 pftf EDK2
( https://github.com/pftf/RPi4 ) related build has 2
patches to EDK2:

=C2=A0- name: Patch EDK2 repositories
=C2=A0 =C2=A0 =C2=A0 run: |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2 -p1 -i ../0001-MdeModule= Pkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2-platforms -p1 -i ../0002= -Check-for-Boot-Discovery-Policy-change.patch

These would not be in the FreeBSD port's build.

FYI, for the RPi4 EDK2:

=C2=A0 =C2=A0 - name: Download Raspberry Pi support files
=C2=A0 =C2=A0 =C2=A0 run: |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.START_ELF_VERSION }}/boot/fixup4.dat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.START_ELF_VERSION }}/boot/start4.elf
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTB_VERSION }}/boot/bcm2711-rpi-4-b.dtb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTB_VERSION }}/boot/bcm2711-rpi-cm4.dtb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTB_VERSION }}/boot/bcm2711-rpi-400.dtb
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTBO_VERSION }}/boot/overlays/miniuart-bt.dtbo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTBO_VERSION }}/boot/overlays/upstream-pi4.dtbo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mkdir overlays
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mv *.dtbo overlays

(I add and use disable-bt.stbo . They do mention its use in
some instructions someplace.)

> and didn't
> find a flavor for rpi2. This was on a Pi4 running -current.

I supplied notes about RPi2B's earlier, above.

> It's unclear to me if edk2 offers any advantage over u-boot, at le= ast
> when u-boot works.

I only suggested EDK2 because U-Boot was not working
well and there might be a chance that EDK2 might work
better for for that stage in one or more of your
detailed contexts. (No claim that this would improve
FreeBSD kernel handling of any RPi*/bridge/drive
combinations --or the earlier RPi* firmware stage.)

If it does not work better for any, I'd suggeste avoiding
being outside the somewhat supported FreeBSD RPi* context:
avoid EDK2.

(I use both styles of booting, but I'm odd.)

I'll note that the main ports has updated U-Boot's
from 2022.04 to 2022.10 . No clue if you might see
behavioral changes for the U-Boot stage if you
update.

Also, Warner L. has checked in a fix for main FreeBSD's
EFI loader build ( in stand/efi/ ) for armv7(/armv6).
The next snapshot for armv7 main [so: 14] should have
it.

> I think HPS's changes to usb probably did help,

Good.

> but
> won't know for a while yet given the erratic nature of the trouble= s.

Yep.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--000000000000deb6c305ebd4aece--