Re: Using loader to switch kernel and root device on Pi2

On Apr 3, 2025, at 11:20, bob prohaska <fbsd@www.zefox.net> wrote:

> On Thu, Apr 03, 2025 at 10:26:11AM -0700, Mark Millard wrote:
>> 
>> 
>> So CONFIG_IS_ENABLED(ENV_SUPPORT) is required to be able to
>> override the default value involved. I've not checked if the
>> FreeBSD U-Boot ports are enabling that or not.
>> 
> 
> Some experiments suggest it is not enabled. I've tinkered
> with config.txt

If you mean the likes of:

# ls -lodT /boot/efi/config.txt
-rwxr-xr-x  1 root wheel uarch 1480 Jan  4 11:50:04 2024 /boot/efi/config.txt

That file is for the RPi* firmware only. It is ignored by
U-Boot --and always has been. It is also ignored by the
FreeBSD loader, by the FreeBSD kernel, and by the FreeBSD
world. It is only read and used by the RPi* firmware.

(There is a cmdline.txt allowed intended for text supplied
to the (linux) "kernel" "command line". I've no clue if
U-Boot has the same "command line" interface as the linux
kernel. Similarly for if the FreeBSD kernel does vs. not.)

> and don't see corresponding changes in 
> output from printenv at the u-boot prompt.

As should be the case.

> But, this touches on my longstanding point of confusion:
> Is config.txt read by u-boot, or by bootcode.bin with
> the values passed to u-boot? Or maybe both?

config.txt does not supply anything U-Boot specific
to U-Boot at all. usb_pgood_delay is U-Boot specific,
not part of the RPi* firmware.

> The Raspberry Pi docs mention quite a few time delay variables:
> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
> 
> USB_MSD_DISCOVER_TIMEOUT
> USB_MSD_LUN_TIMEOUT
> USB_MSD_STARTUP_DELAY
> 
> Increasing those values to
> USB_MSD_DISCOVER_TIMEOUT=20000
> USB_MSD_LUN_TIMEOUT=2000
> USB_MSD_STARTUP_DELAY=5000
> does seem to slow down the boot process.

The above are all RPi* firmware things, not U-Boot
things. They are involved even for forms of booting
that do not have U-Boot present.

Those all happen before U-Boot is started. If/when
U-Boot resets the USB bus, the above have no impact
on U-Boot waiting for the reset to complete all its
intended consequences.

> Alas, it does not seem
> to improve disk detection reliability on a warm boot.

Relative to U-Boot's handling of the USB bus, that is
as intended. U-Boot does its own thing for such.


===
Mark Millard
marklmi at yahoo.com