From nobody Sun Dec 19 04:34:22 2021 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 2398018F7F6B for ; Sun, 19 Dec 2021 04:34:25 +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 4JGqcc4cTRz53VP for ; Sun, 19 Dec 2021 04:34:24 +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 1BJ4YN9X012912 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 20:34:23 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJ4YNTL012911; Sat, 18 Dec 2021 20:34:23 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Dec 2021 20:34:22 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219043422.GA12811@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@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: <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> X-Rspamd-Queue-Id: 4JGqcc4cTRz53VP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 18, 2021 at 05:19:49PM -0800, Mark Millard wrote: > > > On 2021-Dec-18, at 14:35, bob prohaska wrote: > > > I even tried putting usb_pgood_delay=20000 in config.txt, > > Wrong place: usb_pgood_delay is only for U-Boot, not the RPi* > firwmare. It does nothing useful in config.txt on an RPi* . > I was hopeful that maybe u-boot might pick up the environment from the earlier-running firmware. Evidently not. > As stands the only ways I know to supply usb_pgood_delay > to U-Boot are: > > A) Type its assignment into the U-Boot prompt. > B) Build the *u-boot*.bin in question with the value assigned > at build time. > > To my knowledge (B) has yet to be tried. Any test of > usb_pgood_delay that did not involve (A) was a > wrong-context test and does not apply. > > That includes any testing about seconds vs. milliseconds. I > expect that usb_pgood_delay is in milliseconds in U-Boot. > > > Usb reset finds the disk after one to about six tries, seemingly > > at random, regardless of > > usb_pgood_delay > > bootcode.bin_delay > > ".bin"? Wrong name. use: bootcode_delay= > Sorry, misreported. The actual line in config.txt on microSD is bootcode_delay=10 > > It will probably be a while before I look at > > http://www.zefox.net/~fbsd/slow_usb_notes > > but it may be that some experiments need to be replaced/re-run > based on usb_pgood_delay being provided in the wrong place > and the bootcode.bin_delay wrong name being used. Experiments using editenv usb_pgood_delay from 0 to 20 s while in u-boot were tried. I could not detect any _consistent_ improvement. Sometimes the disk enumerated on the next usb reset, but often enough it made no difference. More confusingly, simply repeating usb reset without doing anything else has always enumerated the disk within (so far) six tries. I'll keep playing with it, especially now that the hub has been removed, but if the timing is fussy a persistent loop seems more dependable. Thanks for writing! bob prohaska