Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

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
>
>
>