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

On 2022-Sep-26, at 10:09, bob prohaska <fbsd@www.zefox.net> wrote:

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

Remember that, overall, I'm not familiar with building
or developing U-Boot.

Looking around it seems that there is a file:

https://github.com/ARM-software/u-boot/blob/master/Kconfig

that includes other files, such as:

https://github.com/ARM-software/u-boot/blob/master/common/Kconfig

that contains descriptions of things like the below under its
'menu "Logging"' section (not directly #define names here: CONFIG_
would be prefixed to the name on the right):

config LOGLEVEL
config LOG
config SPL_LOG
config LOG_MAX_LEVEL
config SPL_LOG_MAX_LEVEL
config LOG_CONSOLE
config LOG_SPL_CONSOLE

It looks like this is used as part of seting up what to
allow to be controlled via the likes of:

# make menuconfig

in a normal U-Boot context (which ports is not).

rpi_arm64_defconfig looks like it might be a result of
use of that.

So, specifically for the symbols:

CONFIG_LOGLEVEL
CONFIG_LOG
CONFIG_SPL_LOG
CONFIG_LOG_MAX_LEVEL
CONFIG_SPL_LOG_MAX_LEVEL
CONFIG_LOG_CONSOLE
CONFIG_LOG_SPL_CONSOLE

you are likely right about where the definitions go.

But it seems likely that only things described in some
used Kconfig file ( such as common/Kconfig ) would go
in rpi_arm64_defconfig . So other symbols I(if any)
likely go elsewhere.

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

So you blame U-Boot instead of your drive/bridge combination.
I've no clue what the detailed issue is that leads to the
mismatch.

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

The kernel and world do not have to be on the same media but
splitting them makes for a non-standard updating sequence to
be needed. Somewhat more than the kernel must have
copies/variants on the same media as the kernel because a
couple (or so) files are accessed so early.

I do this on the Rock64 in order to allow world to run from
the USB3 port. (Its U-Boot did not know how to deal with
that USB3 port last I checked. But the FreebBSD kernel does.)
So the kernel used is not on the USB3 media but the world's
materials are.

Going this sort of route of not getting the kernel from the
USB drive, you would need to figure out how you want to do
updates to the kernel and world. Some things may need copies
in both places.

The EFI material would go on the same media as the kernel but
in a msdosfs file system with the proper path in that file
system.

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

That is not what I did. (Warning: In my environment I use
lower case names in places where FreeBSD by default uses
upper case. The below shows upper case. This makes clearer
just which thing is being referenced. My use of lower case
was not a good idea.)

/boot/efi is in the UFS (or ZFS) file system and is a mount
point. The thing mounted to/in it is the msdosfs file system.
That file system contains the likes of a path:

EFI/BOOT/bootaa64.efi

(which is the path that U-Boot looks for to find the
EFI material).

Having the msdosfs file system mounted at /boot/efi leads to
the path:

/boot/efi/EFI/BOOT/bootaa64.efi

(starting from a UFS/ZFS context and reaching into msdosfs).

Note that in U-Boot /boot/efi is not involved: FreeBSD has
not even been started that that point and there is no
active UFS/ZFS file system yet. So no /boot/efi is active.
U-Boot directly deals with the msdosfs itself.

What I did do was to change (on the msdosfs):

EFI/BOOT/bootaa64.efi

to the likes of:

EFI_disabled/BOOT/bootaa64.efi

This prevents U-Boot from finding/using that copy of the
EFI material --so U-Boot looks elsewhere until it finds
an example of:

EFI/BOOT/bootaa64.efi

if it manages to find such. That EFI in turn finds
FreeBSD's kernel in other partitions on the same
media as that EFI (at least by default).

So I have an msdosfs partition on the same media as the
kernel and that msdosfs contains a proper file with the
path:

EFI/BOOT/bootaa64.efi

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

The point of the note was that it would liklely *not*
do the trick. In your problem context you have to avoid
U-Boot trying to use the USB drive at all or the problem
likely would just repeat.

The problem is not where U-Boot is loaded from. The problem
is U-Boot and your USB drive configuration do not work
together overall when U-Boot tries to get the USB drive
set up for U-Boot's use. Avoiding U-Boot trying to use the
USB drive at all would avoid hitting the mismatch
consequences.

===
Mark Millard
marklmi at yahoo.com