Date: Mon, 24 Oct 2022 20:32:17 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: 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: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com> In-Reply-To: <20221025005012.GA80394@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> 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. >>=20 >> 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. >>=20 > 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. >=20 >>=20 >>> 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. >>=20 >>=20 >> 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 >>=20 >=20 > 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=3D 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=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.) 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.dt= b curl -O -L = https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b-pl= us.dtb curl -O -L = https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-cm3.dt= b (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.=20 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.=20= Yep. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?605A6723-5D31-495C-8200-FD107115FC81>