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

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