Date: Wed, 21 Sep 2022 09:17:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> In-Reply-To: <20220921154240.GA37735@www.zefox.net> References: <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> <20220921154240.GA37735@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-21, at 08:42, bob prohaska <fbsd@www.zefox.net> wrote: > On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote: >>=20 >> 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. >>=20 >> 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: >>=20 >> # more = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20= >> --- 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=3D2000\0" \ >> + "usb_ready_retry=3D5\0" \ >> BOOTENV >>=20 >>=20 >>=20 >=20 > You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3. > Does that matter? The description seems to imply not. u-boot-rpi-arm64 works for both RPi3B and RPi4B and is what the snapshot and release images for them are based on in modern times. I used to have my RPi* U-Boots be based on u-boot-rpi3 and u-boot-rpi4 before u-boot-rpi-arm64 was created and used for snapshots and releases. But I changed to track the actively used variant as the basis for my builds and installs of U-Boot for the aarch64 RPi*'s. But I still have the same patch in place for u-boot-rpi3 and for u-boot-rpi4 : # more /usr/ports/sysutils/u-boot-rpi3/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=3D2000\0" \ + "usb_ready_retry=3D5\0" \ BOOTENV =20 =20 # more /usr/ports/sysutils/u-boot-rpi4/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=3D2000\0" \ + "usb_ready_retry=3D5\0" \ BOOTENV =20 =20 For my boot media, all 3 U-Boots need the patch. For RPi4B's in my context, the turbo status is needed for both RPi4B U-Boot variants. (Unsure for RPi3B's.) >> #1: >>=20 >> I'm unsure if this applies to more than RPi4B's and the like . . . >>=20 >> 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: >>=20 >> init_turbo=3D60 # or other sufficient number of seconds >>=20 >> or, if I'm always after turbo mode for general operation, >>=20 >> force_turbo=3D1 >>=20 >> in config.txt to avoid the failure. >>=20 >=20 > A few experiments with either (but not both) > initial_turbo=3D60 [spelling per rpi docs, hope that's right] or > force_turbo=3D1=20 > didn't have obvious effect. Sometimes found disk, sometimes didn't. As I said, I had problems unless both the patch and the turbo status were in place --but on RPi4B's. I do not actively use a RPi3B but do have access to one. If needed I could at some point try the RPi3B via a powered hub being involved. > 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.=20= > It's unclear to me if timeout affects both firmware and u-boot, or > just firmware.=20 I also have and leave in place the timeout file. But I've not tried to determine if it was necessary for the RPi4B's in some time. Having it just means one fewer thing to deal with possibly contributing. >=20 >=20 >> 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. >>=20 >> A powered hub being involved adds complications not invovled >> in my context. >>=20 >=20 > 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. I seem to remember discussions of startup current requirements for some spinning rust in your RPi3B context. (The power situation for RPi4B's is far less problematical.) >>=20 >> 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. >>=20 >=20 > Ahh, I thought u-boot inherited at least some environmental > details from the firmware. Thanks for the clarification! Resetting the bus and reenumating the media is how the not-found status happens. That is what the block of output from U-Boot is about for the 0 found message (and somewhat before). >> 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CC2A42B-21AC-44C6-BD02-44D320CADF63>