Date: Mon, 26 Sep 2022 10:09:13 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <20220926170913.GA68300@www.zefox.net> In-Reply-To: <ACC55AE8-9394-49C8-BA85-221D64B11FDF@yahoo.com> References: <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net> <DBD238AA-8C65-46D2-87CC-A9875C6959BF@yahoo.com> <20220925193415.GA63733@www.zefox.net> <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com> <20220926010420.GA64437@www.zefox.net> <ACC55AE8-9394-49C8-BA85-221D64B11FDF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 25, 2022 at 09:47:55PM -0700, Mark Millard wrote: > > I'll note that: > > https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h > > shows it #defines some other CONFIG_... names, including > the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ). > This is at least suggestive. But it may be some other .h file > would have to be used instead. > Looking at root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/configs # more rpi_arm64_defconfig CONFIG_ARM=y CONFIG_ARCH_BCM283X=y CONFIG_SYS_TEXT_BASE=0x00080000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_RPI_ARM64=y CONFIG_ENV_SIZE=0x4000 CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b" .... the entries in the file look to be of the right format, although it it's a .h file. Adding a few lines looks like an easy experiment, even if it's not the "correct" way. > > Going in a different direction: Having the RPi* firmware and > U-Boot load from a microsd card but the EFI material from > the USB media likely would do you no good. U-Boot would still > have to get the USB media working for its activity in order > for U-Boot to find and load the EFI material that is on the > USB media. It is the same problem again. > U-boot seems biased toward booting a microSD, which works very well. Given that the FreeBSD kernel seems to have no trouble with the disk, might it make sense to boot a small FreeBSD system from a microSD and then run some sort of single-user script to find and re-boot from the USB device? All the machinery of the kernel and system would be available to gather system information for the (re)-boot step. I originally thought that's how it would be done. However, I'm no programmer. As you've doubtless noticed 8-) It's roundabout, but u-boot seems to be a fairly black box. Great when it works, inscrutable when it doesn't. [snipped] > > The above does not have FreeBSD present and has made the EFI > material on the microsd card be not-found (via using the > efi_disabled directory name instead). This leads U-Boot to > find the EFI material on the USB media instead --where it > has the normal path related names. > Can you explain a little more how renaming /boot/efi to /boot/efi_disabled works? If that forces u-boot on the microSD card to search for usb devices again it might do the trick for me. Or, do I misunderstand your intent? Thanks for writing! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220926170913.GA68300>