From nobody Mon Jun 07 23:52:48 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 361CF13EC75D for ; Mon, 7 Jun 2021 23:53:53 +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 4FzVZR1JqMz4mLm for ; Mon, 7 Jun 2021 23:53:46 +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 157NrNgj013120 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Jun 2021 16:53: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 157NrKB4013119; Mon, 7 Jun 2021 16:53:20 -0700 (PDT) (envelope-from fbsd) Date: Mon, 7 Jun 2021 16:52:48 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210607235248.GB11184@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> 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: X-Rspamd-Queue-Id: 4FzVZR1JqMz4mLm 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 Mon, Jun 07, 2021 at 01:09:52PM -0700, Mark Millard wrote: > > > On 2021-Jun-7, at 11:40, bob prohaska wrote: > > > On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm wrote: > > Looking around on the web I see reports of the: > > Request Sense returned 02 04 01 > > (and the matching Device NOT ready) mean that the > problem will occur and that repeating usb start > or usb reset again until it does not report that > leads to things working. > > But I've also seen other, more complete information > indicating that there is a environment setting > (showing an example value): > > usb_ready_retry=5 > > to set up before the usb restart (or usb start) > command. It deals with the issue more explicitly > for slow devices. > > Another one is (units: msec): > > usb_pgood_delay=10000 > Presto! using editenv usb_pgood_delay prompted for input, typing 10000 and hitting return set the value and the disk was found. It looks like the setting can only be saved to microSD. With no card saveenv reports Saving Environment to FAT... Card did not respond to voltage select! Failed (1) > There are also device that have problems with > large transfers and require extra protocol to > deal with transfer problems before they will > work again, U-Boot not doing that. > > usb_max_blk=20 > > sets a old historical value that generally > just works for such devices form what I read. > > I see no indication that other usb commands are > worthwhile until one has avoided that "Request > Sense returned 02 04 01" message for usb reset > (a.k.a. usb start). > > The reports of this sort of thing are not limited > to RPi's and go back to at least 2014. > > If I understand correctly, usb_ready_retry and > usb_pgood_delay and usb_max_blk are part of > normal U-Boot builds these days. But I'm not > certain of that. > > > I will note: > > QUOTE > Common USB Commands: > - usb start: > - usb reset: (re)starts the USB. All USB devices will be > initialized and a device tree is build for them > - usb tree: shows all USB devices in a tree like display > . . . > > Storage USB Commands: > - usb scan: scans the USB for storage devices.The USB must be > running for this command (usb start) > . . . > END QUOTE > > Note that the wording indicates that having the tree is not > the same as having classified the storage devices: storage > classification is an seprate step. > I didn't appreciate how independent u-boot's usb commands are. Info and tree could see the disk but dev, storage and reset didn't. > > > As an experiment, I tried booting with no microSD card installed at > > all. This got confusing; u-boot still came up, apparently from the > > USB hard drive. > > The RPi internal code is handling the USB drive > initially and loading the RPifirmware from the > USB drive. That firmware is in turn loading > U-Boot in this case. > > It is when U-Boot tries to take over and set up > the USB drive for its own use that things are > having the problem. > [regarding earlier, intermittent failures] > But did the problem cases show: > > Request Sense returned 02 04 01 > > or: > > Device NOT ready > > ? Or were such details different? > Not sure. When I saw that the disk wasn't detected, I waited a few seconds and re-ran usb reset. Within a few tries the disk was found. > It's unclear to me what changed, probably something I did, but setting u-boot environment variable usb_pgood_delay=10000 seems to have put matters right again. Thank you! bob prohaska