From nobody Wed Sep 21 15:42:40 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MXjNR1h9bz4cpld for ; Wed, 21 Sep 2022 15:42:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MXjNP6qvPz3G2f for ; Wed, 21 Sep 2022 15:42:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28LFgfCm040517 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 21 Sep 2022 08:42:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 28LFgfrb040516; Wed, 21 Sep 2022 08:42:41 -0700 (PDT) (envelope-from fbsd) Date: Wed, 21 Sep 2022 08:42:40 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <20220921154240.GA37735@www.zefox.net> References: <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> X-Rspamd-Queue-Id: 4MXjNP6qvPz3G2f X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-0.99 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.98)[-0.980]; NEURAL_HAM_MEDIUM(-0.92)[-0.917]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[zefox.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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