From nobody Wed Jun 29 14:33:37 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 E864E86C34D for ; Wed, 29 Jun 2022 14:35:05 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LY3s50srVz4gkl for ; Wed, 29 Jun 2022 14:35:05 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 25TEXbxr026509 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 29 Jun 2022 07:33:37 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 25TEXbOm026508; Wed, 29 Jun 2022 07:33:37 -0700 (PDT) (envelope-from warlock) Date: Wed, 29 Jun 2022 07:33:37 -0700 From: John Kennedy To: Bradley Proffit Cc: freebsd-arm@freebsd.org Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is attached Message-ID: References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital> 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: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital> X-Rspamd-Queue-Id: 4LY3s50srVz4gkl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [-1.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.953]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 29, 2022 at 02:06:14AM -0700, Bradley Proffit wrote: > I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual > SATA-to-USB hard drive docking station, and I've noticed a peculiar > situation: U-Boot fails to load FreeBSD from the SD card when the > docking station is plugged in and has two hard drives in it (presenting > two USB storage devices to U-Boot), but still succeeds when: > > 1. the device is not attached; > 2. the device is attached but only has one hard drive in it, presenting > one USB storage device to U-Boot; > 3. when the device with one hard drive in it, and another USB storage > device, such as a flash drive, are plugged in. At the risk of sharing totally irrelevant experiences, here is mine. I just got what should be a 4B. It very happily "just worked" USB-only (no SDCARD) out of the box. I've got it connected to a single USB M.2 carrier that's made me very happy. I'm not sitting in front of it so can't provide more useful comparisons at the moment. I see that reference to (e)mmc and think of your SDCARD. If I just had an empty carrier I tended to see OS-level media-not-ready errors, not sure what u-boot would report that as. If it's just an empty slot and that's uboot's way of noticing that, great. Red herring. If I was sitting in front of mine I might be able to compare. I'm a little worried seeing those DHCP type alerts. That implies to me that it is trying to network boot. Great if that's what you want, distracting if it isn't. If this was my traditional BIOS, I'd be reaching for the boot-order knobs but since mine just worked, I haven't dug into that type of setup yet. Sandwiched inbetween the failed MMC stuff and the DHCP stuff is it seeing a reference to "ASM1156-PM" Hard Disk with a realistic size. I'd take that to mean that it's gone and properly scanned it (so no missing media). As you theorized, maybe exceeding USB port-power could cause the device to disappear soon after probing (and maybe uboot wouldn't note that in a way we could see here). I didn't see a probe of the 2nd drive (but maybe being done sequentially and we haven't gotten to it yet). I don't know if you have the option of pulling it off the dock and plugging it into a differently-powered USB port or if that was the whole point of the dock. I could swear that I've seen some long RPI-boot-from-USB threads from Bob P that might help you eyeball this at the uboot level. If you can have it booted up and enumerate everything at the uboot level then it probably isn't a power issue, especially if you can boot it manually via that interface, but you still want an unattended reboot. After probing that one drive, it looks like it just goes right onto trying to PXE-boot off the network and fails. Can you tell from the output which drive it found? (Basically size, but maybe brand) In particular, is it the drive with the next-stage EFI boot that I think uboot is looking for at that point? If the non-boot drive powered up faster than the boot drive, uboot might see it first whenever it was plugged in, and maybe it'd get ignored if it didn't have the EFI partition. Wouldn't explain why the other drive wasn't probed, of course.