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

On Apr 3, 2025, at 10:26, Mark Millard <marklmi@yahoo.com> wrote:

> ob prohaska <fbsd_at_www.zefox.net> wrote on

Bob

> Date: Thu, 03 Apr 2025 16:07:30 UTC :
> 
>> On Wed, Apr 02, 2025 at 06:57:23PM -0600, Warner Losh wrote:
>>> 
>>> No. Loader.env is EFI specific and read super early in the setup so you can
>>> change the loaddev or currdev.
>> 
>> Is it early enough to influence the behavior of u-boot? I'm looking to 
>> add a delay of a few seconds for mechanical disk detection. There was
>> a config.txt variable usb_pgood_delay for that purpose, but it's gone
>> from the documentation AFAICT.
> 
> 
> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
> 
> has in usb_hub_power_on(. . .):
> 
> . . .
> 	unsigned pgood_delay = hub->desc.bPwrOn2PwrGood * 2;
> 
> 	. . .
> 
> 	/*
> 	 * Wait for power to become stable,
> 	 * plus spec-defined max time for device to connect
> 	 * but allow this time to be increased via env variable as some
> 	 * devices break the spec and require longer warm-up times
> 	 */
> #if CONFIG_IS_ENABLED(ENV_SUPPORT)
> 	env = env_get("usb_pgood_delay");
> 	if (env)
> 		pgood_delay = max(pgood_delay,
> 			          (unsigned)simple_strtol(env, NULL, 0));
> #endif
> 	debug("pgood_delay=%dms\n", pgood_delay);
> 
> 	/*
> 	 * Do a minimum delay of the larger value of 100ms or pgood_delay
> 	 * so that the power can stablize before the devices are queried
> 	 */
> 	hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
> 
> 	/*
> 	 * Record the power-on timeout here. The max. delay (timeout)
> 	 * will be done based on this value in the USB port loop in
> 	 * usb_hub_configure() later.
> 	 */
> 	hub->connect_timeout = hub->query_delay + HUB_DEBOUNCE_TIMEOUT;
> 	debug("devnum=%d poweron: query_delay=%d connect_timeout=%d\n",
> 	      dev->devnum, max(100, (int)pgood_delay),
> 	      max(100, (int)pgood_delay) + HUB_DEBOUNCE_TIMEOUT);
> 
> 
> 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.

It appears that u-boot-bhyve-arm64 is the only U-Boot explicitly
doing CONFIG_ENV_SUPPORT :

# grep -r ENV_SUPPORT /usr/ports/sysutils/u-boot-*/
/usr/ports/sysutils/u-boot-bhyve-arm64/files/patch-configs_bhyve__arm64__defconfig:+CONFIG_ENV_SUPPORT=y

It appears that u-boot-bhyve-* have the only examples of
defconfig patches :

# find -s /usr/ports/sysutils/u-boot-*/ -name '*defconfig*' -print
/usr/ports/sysutils/u-boot-bhyve-arm64/files/patch-configs_bhyve__arm64__defconfig
/usr/ports/sysutils/u-boot-bhyve-riscv/files/patch-configs_bhyve-riscv64_smode_defconfig

So the CONFIG_ENV_SUPPORT and defconfigstatus appears to be as in the
upstream for the rest of the u-boot-*/ . 

No u-boot-*/ mentions pgood :

# grep -ri pgood /usr/ports/sysutils/u-boot-*/
# 

So nothing appears to patch the usb_pgood_delay handling.

Overall: the usb_pgood_delay status seems to be whatever it
was upstream.

===
Mark Millard
marklmi at yahoo.com