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

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Apr 3, 2025, at 10:26, Mark Millard <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.