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

Reply: Warner Losh : "Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
In reply to: bob prohaska : "Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Tue, 25 Oct 2022 03:32:17 UTC
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:

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

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

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