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

On Thu, Apr 03, 2025 at 11:52:01AM -0700, Mark Millard wrote:
> On Apr 3, 2025, at 11:20, bob prohaska <[email protected]> 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.

That clears up several grave misconceptions on my part.
It now seems that usb detection failures are between
u-boot and the disk hardware.  

Thank you!

bob prohaska