From nobody Tue Sep 27 16:03:28 2022 X-Original-To: freebsd-ports@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 4McPYW2LgPz4V7Nq; Tue, 27 Sep 2022 16:03:27 +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 4McPYV0hx2z3lqx; Tue, 27 Sep 2022 16:03:25 +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 28RG3SvX071825 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 27 Sep 2022 09:03:29 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 28RG3S0j071824; Tue, 27 Sep 2022 09:03:28 -0700 (PDT) (envelope-from fbsd) Date: Tue, 27 Sep 2022 09:03:28 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD Mailing List , freebsd-arm Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <20220927160328.GA71742@www.zefox.net> References: <20220921154240.GA37735@www.zefox.net> <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net> <20220925193415.GA63733@www.zefox.net> <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com> X-Rspamd-Queue-Id: 4McPYV0hx2z3lqx 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 [-1.00 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.904]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,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 Sun, Sep 25, 2022 at 04:43:15PM -0700, Mark Millard wrote: [snip] > > Because USB3 introduces various differences, some testing > via the RPi4B USB2 ports is appropriate. > That turns out to be an easy experiment. Here's a summary: I have two identical mass storage devices (Seagate Barracuda 1TB) in identical Sabrent EC-UASP USB-SATA enclosures. One runs an old installation of -current and is connected to a Pi4. The other runs a recent 13-stable via a Sabrent USB 3 powered hub to a Pi3B. Neither machine has a microSD card installed. For as long as I've had them, the Pi4 running -current has booted reliably and the Pi3 running 13-stable has failed u-boot's disk discovery on reboot around half the time. When u-boot succeeded, the 13-stable system ran perfectly until rebooted. After swapping the disks, enclosures and cables between Pi4 and Pi3 (including the hub) both machines booted on the first try, every try. Moving the 13-stable (troublesome) disk to the Pi4's USB 2 port didn't cause any problems either. The disk continued to boot. Restoring the original setup restored the boot failures. The u-boot versions are different: 13-stable uses u-boot-rpi-arm64, compiled yesterday. The -current disk still uses the u-boot that came with the snapshot used to set up the disk, reporting U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000) Config.txt is identical apart from force_turbo=1 on 13-stable, which didn't make any visible difference when added. Using the older u-boot on the 13-stable disk didn't have any effect. Are there any other files that alter u-boot behavior? It's hard to see how the hub's at fault, since it works with -current. I did look at common/usb.c but it's far from obvious how one can turn on the logging feature so as to report more errors to the console. Thanks for reading and replying! bob prohaska