Date: Mon, 24 Oct 2022 22:52:51 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, "Klaus K??chemann" <maciphone2@googlemail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <CANCZdfpa3AaMwGHDSxaSafUBim_4eiXrYvrb5QMVSgjAJwED9g@mail.gmail.com> In-Reply-To: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com> References: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com> <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com> <DC32CA76-5072-4521-BCD8-CDF1512420D4@yahoo.com> <20221021175142.GA62386@www.zefox.net> <B90AA192-17B4-4FE3-8050-1E7889432ED4@yahoo.com> <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> <DBA8B2E1-D596-4664-A6F3-893C43265317@yahoo.com> <20221025005012.GA80394@www.zefox.net> <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000deb6c305ebd4aece Content-Type: text/plain; charset="UTF-8" On Mon, Oct 24, 2022 at 9:32 PM Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Oct-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 "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 <imp@FreeBSD.org> 2022-01-07 05:34:18 +0000 > committer Warner Losh <imp@FreeBSD.org> 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 <marklmi26-fbsd@yahoo.com> 2022-10-21 > 21:47:14 +0000 > >> committer Lorenzo Salvadore <salvadore@FreeBSD.org> > 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 <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 24, 2022 at 9:32 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 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-O= ct-24, at 17:50, bob prohaska <<a href=3D"mailto:fbsd@www.zefox.net" tar= get=3D"_blank">fbsd@www.zefox.net</a>> wrote:<br> <br> > On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:<br> >> <br> >> bootcode.bin is only likely to help stages before<br> >> u-boot.bin starts. If it makes to to u-boot.bin<br> >> starting, bootcode.bin is then likely irrelevant<br> >> from then on.<br> >> <br> >> In fact bootcoce.bin is what loads the start*.elf<br> <br> Typo fix: bootcode.bin<br> <br> >> that is used. If the start*.elf starts, bootcode.bin<br> >> is likely irrelevant past that point.<br> >> <br> > I've put the console output at<br> > <a href=3D"http://www.zefox.net/~fbsd/rpi2/20221024/boot_console" rel= =3D"noreferrer" target=3D"_blank">http://www.zefox.net/~fbsd/rpi2/20221024/= boot_console</a><br> > in case it's of interest.<br> <br> It was a RPi2B v1.1 (Cortex-A7 form of armv7).<br> <br> It was a U-Boot 2022.04 based boot sequence for<br> the U-Boot stage.<br> <br> swapon: /dev/sdda0s2b: No such file or directory looks<br> like us has an incorrect "sd" between "/" and "da0= s2b".<br> <br> I've not seen/noticed the following before:<br> <br> QUOTE<br> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat/pkg /usr/local/lib/compat/pkg<br> Soft Float compatibility ldconfig path:<br> ldconfig: illegal option -- o<br> usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file ...= ]<br> END QUOTE<br> <br> But, to my knowledge, "Soft Float" is not in use any more<br> (by default, anyway). It might be that something is left<br> over from long ago? Looking, I see:<br></blockquote><div><br></div><div>I w= as sure that all attempts to use it in FreeBSD 12+ had been removed....</di= v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> QUOTE<br> author=C2=A0 Warner Losh <imp@FreeBSD.org>=C2=A0 =C2=A02022-01-07 05:= 34:18 +0000<br> committer=C2=A0 =C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>=C2= =A0 =C2=A02022-01-07 05:34:18 +0000<br> commit=C2=A0 d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)<br> tree=C2=A0 =C2=A0 14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e /libexec/rc/rc.d= /ldconfig<br> parent=C2=A0 b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)<br> download=C2=A0 =C2=A0 =C2=A0 =C2=A0 src-d418bc27e601ec6bba0506d0efb62eca5ed= a5ab8.tar.gz<br> src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip<br> <br> libsoft: Remove runtime ldconfig support for libsoft<br> <br> Remove the runtime support for running ldconfig at boot to cache lists<br> of libsoft libbraries.<br> END QUOTE<br> <br> ( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .)<br> <br> Your /etc/rc.d/ldconfig script seems to have not been updated<br> by use of etcupdate or mergemaster or other such. (How much<br> else is also out of date? How much of what you have for /etc/<br> and the like goes back to 2022-Jan-07 or before?)<br></blockquote><div><br>= </div><div>Yea... that seems likely... Can you confirm that I've not me= ssed up</div><div>a merge somewhere?</div><div>=C2=A0</div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"> > There are a surprising number<br> > of what look like complaints/errors, but it boots anyway.<br> > <br> >> <br> >>> The interest I expressed in EDK2 appears to have been misguide= d,<br> >>> or at least premature. I was hoping it might be a more tractab= le<br> >>> replacement for u-boot, but it's equally inscrutable to an= amateur.<br> >> <br> >> <br> >> Was this based on mina ports before vs. after:<br> <br> Another wonderful typo of mine: "mina".<br> <br> >> QUOTE<br> >> author=C2=A0 =C2=A0 =C2=A0 =C2=A0Mark Millard <<a href=3D"mailt= o:marklmi26-fbsd@yahoo.com" target=3D"_blank">marklmi26-fbsd@yahoo.com</a>&= gt; 2022-10-21 21:47:14 +0000<br> >> committer=C2=A0 =C2=A0 Lorenzo Salvadore <salvadore@FreeBSD.org= >=C2=A0 =C2=A0 =C2=A0 =C2=A02022-10-21 22:00:03 +0000<br> >> <br> > <br> > 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<br> > how to make poudriere attempt to build the needed rpi3 flavor<br> <br> (The FLAVORS material below is more for providing<br> background in building flavored ports than for EDK2<br> specifically, but using EDK2 as the example . . .)<br> <br> The sysutils/edk2/Makefile has:<br> <br> FLAVORS=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 macchiatobin fvp rpi3 rpi4 xen_x64 bh= yve qemu_x64 qemu_i386<br> <br> Being listed first, macchiatobin is the default flavor. To specify<br> a flavor explicitly on the poudriere bulk command, use notation<br> like one or more of the following on the command line:<br> <br> sysutils/edk2@macchiatobin<br> sysutils/edk2@fvp<br> sysutils/edk2@rpi3<br> sysutils/edk2@rpi4<br> <br> So the last 2 of those 4 are the ones that fit your<br> context. (The later ones in the FLAVORS list have:<br> ONLY_FOR_ARCHS=3Damd64 .)<br> <br> Other than flavors handling . . .<br> <br> I've commented before that I'm not aware of an<br> armv7 EDK2. So no coverage of an RPi2 v1.1 as<br> far as I know. ( Also known via any of its<br> dtb names, such as: bcm2709-rpi-2-b.dtb .<br> bcm2710-rpi-2-b.dtb is the v1.2 aarch64<br> variant.)<br></blockquote><div><br></div><div>Yea, we get our UEFI support = via u-boot there...</div><div><br></div><div>Warner</div><div><br></div><di= v>=C2=A0</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"> The RPi3 EDK2 only supplies the RPi* firmware that<br> it gets via curl when the official RPi3 pftf EDK2<br> ( <a href=3D"https://github.com/pftf/RPi3" rel=3D"noreferrer" target=3D"_bl= ank">https://github.com/pftf/RPi3</a>; ) related builds are done:<br> <br> =C2=A0 =C2=A0 - name: Download Raspberry Pi support files<br> =C2=A0 =C2=A0 =C2=A0 run: |<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/bootcode.bin" rel=3D"noreferrer" target=3D"_= blank">https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin= </a><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/fixup.dat" rel=3D"noreferrer" target=3D"_bla= nk">https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat</a><b= r> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/start.elf" rel=3D"noreferrer" target=3D"_bla= nk">https://github.com/raspberrypi/firmware/raw/master/boot/start.elf</a><b= r> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/bcm2710-rpi-3-b.dtb" rel=3D"noreferrer" targ= et=3D"_blank">https://github.com/raspberrypi/firmware/raw/master/boot/bcm27= 10-rpi-3-b.dtb</a><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/bcm2710-rpi-3-b-plus.dtb" rel=3D"noreferrer"= target=3D"_blank">https://github.com/raspberrypi/firmware/raw/master/boot/= bcm2710-rpi-3-b-plus.dtb</a><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L <a href=3D"https://github.com/raspbe= rrypi/firmware/raw/master/boot/bcm2710-rpi-cm3.dtb" rel=3D"noreferrer" targ= et=3D"_blank">https://github.com/raspberrypi/firmware/raw/master/boot/bcm27= 10-rpi-cm3.dtb</a><br> <br> (FreeBSD's port does not deal with such things at all.)<br> <br> So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3<br> EDK2 would be well behaved with an appropriate vintage<br> bcm2710-rpi-2-b.dtb added or not. I've never tried<br> such.<br> <br> I forgot to mention that the offical RPI4 pftf EDK2<br> ( <a href=3D"https://github.com/pftf/RPi4" rel=3D"noreferrer" target=3D"_bl= ank">https://github.com/pftf/RPi4</a>; ) related build has 2<br> patches to EDK2:<br> <br> =C2=A0- name: Patch EDK2 repositories<br> =C2=A0 =C2=A0 =C2=A0 run: |<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2 -p1 -i ../0001-MdeModule= Pkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2-platforms -p1 -i ../0002= -Check-for-Boot-Discovery-Policy-change.patch<br> <br> These would not be in the FreeBSD port's build.<br> <br> FYI, for the RPi4 EDK2:<br> <br> =C2=A0 =C2=A0 - name: Download Raspberry Pi support files<br> =C2=A0 =C2=A0 =C2=A0 run: |<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.START_ELF_VERSION }}/boot/fixup4.dat<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.START_ELF_VERSION }}/boot/start4.elf<br> =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<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTB_VERSION }}/boot/bcm2711-rpi-cm4.dtb<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTB_VERSION }}/boot/bcm2711-rpi-400.dtb<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTBO_VERSION }}/boot/overlays/miniuart-bt.dtbo<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ = env.DTBO_VERSION }}/boot/overlays/upstream-pi4.dtbo<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mkdir overlays<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mv *.dtbo overlays<br> <br> (I add and use disable-bt.stbo . They do mention its use in<br> some instructions someplace.)<br> <br> > and didn't<br> > find a flavor for rpi2. This was on a Pi4 running -current. <br> <br> I supplied notes about RPi2B's earlier, above.<br> <br> > It's unclear to me if edk2 offers any advantage over u-boot, at le= ast<br> > when u-boot works.<br> <br> I only suggested EDK2 because U-Boot was not working<br> well and there might be a chance that EDK2 might work<br> better for for that stage in one or more of your<br> detailed contexts. (No claim that this would improve<br> FreeBSD kernel handling of any RPi*/bridge/drive<br> combinations --or the earlier RPi* firmware stage.)<br> <br> If it does not work better for any, I'd suggeste avoiding<br> being outside the somewhat supported FreeBSD RPi* context:<br> avoid EDK2.<br> <br> (I use both styles of booting, but I'm odd.)<br> <br> I'll note that the main ports has updated U-Boot's<br> from 2022.04 to 2022.10 . No clue if you might see<br> behavioral changes for the U-Boot stage if you<br> update.<br> <br> Also, Warner L. has checked in a fix for main FreeBSD's<br> EFI loader build ( in stand/efi/ ) for armv7(/armv6).<br> The next snapshot for armv7 main [so: 14] should have<br> it.<br> <br> > I think HPS's changes to usb probably did help,<br> <br> Good.<br> <br> > but<br> > won't know for a while yet given the erratic nature of the trouble= s. <br> <br> Yep.<br> <br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> <br> </blockquote></div></div> --000000000000deb6c305ebd4aece--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpa3AaMwGHDSxaSafUBim_4eiXrYvrb5QMVSgjAJwED9g>