Date: Wed, 21 Sep 2022 08:42:40 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <20220921154240.GA37735@www.zefox.net> In-Reply-To: <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> References: <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote: > > U-Boot resets the bus, re-enumerates the devices, etc. This > can time out or otherwise fail despite prior activity by the > RPi* firmware that managed to use the device. > > My NVMe USB SSD media have such issues with RPI4B's, also > getting 0 found in U-Boot. This is why I build U-Boot using > the patch: > > # more /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h > --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 > +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 > @@ -210,6 +210,8 @@ > ENV_DEVICE_SETTINGS \ > ENV_DFU_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > + "usb_pgood_delay=2000\0" \ > + "usb_ready_retry=5\0" \ > BOOTENV > > > You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3. Does that matter? The description seems to imply not. > #1: > > I'm unsure if this applies to more than RPi4B's and the like . . . > > Booting an RPi* can have the clock speed(s) vary during booting > and this can mess up timeouts/waits/etc. during booting, timing > too early, for example. I use one of: > > init_turbo=60 # or other sufficient number of seconds > > or, if I'm always after turbo mode for general operation, > > force_turbo=1 > > in config.txt to avoid the failure. > A few experiments with either (but not both) initial_turbo=60 [spelling per rpi docs, hope that's right] or force_turbo=1 didn't have obvious effect. Sometimes found disk, sometimes didn't. For what it's worth, I've been using a timeout file, essentially out of habit. Renaming it to no.timeout seems to have no obvious effect. It's unclear to me if timeout affects both firmware and u-boot, or just firmware. > On the RPi4B's I have to boot based on both #0 and #1 being > in place. Either not being in place can lead to the 0 found > status. > > A powered hub being involved adds complications not invovled > in my context. > It might be possible to boot without the powered hub, seems to me it has worked in the past. I'll give that a try again. > > What the RPi* firmware does to get U-Boot in place is not > used by U-Boot for its activity. The RPi* firmware need > not work the same as U-Boot, allowing for differing results. > Ahh, I thought u-boot inherited at least some environmental details from the firmware. Thanks for the clarification! > > I warn that my notes above are based on RPi4B activity, not > RPi3B use. Also, no power hub use is involved. How much > applies to your context is a valid question. Thanks for writing, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220921154240.GA37735>