Re: U-Boot fails to load from SD when a USB dual HDD device is attached

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.