Hi Peter, On Fri, 13 Oct 2023 at 09:22, Peter Robinson <pbrobin...@gmail.com> wrote: > > On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson <pbrobin...@gmail.com> wrote: > > > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass <s...@chromium.org> wrote: > > > > > > Hi, > > > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet <guillaume.gar...@arm.com> > > > wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Peter Robinson <pbrobin...@gmail.com> > > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > > To: Guillaume Gardet <guillaume.gar...@arm.com> > > > > > Cc: mbrug...@suse.com; Ivan Ivanov <ivan.iva...@suse.com>; Simon Glass > > > > > <s...@chromium.org>; u-boot@lists.denx.de > > > > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4 > > > > > > > > > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet > > > > > <guillaume.gar...@arm.com> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > U-Boot 2023.10 does not boot from uSD on RPi4. > > > > > > This has been found on openSUSE Tumbleweed. The only diff we need > > > > > > is: > > > > > > -CONFIG_OF_EMBED=y > > > > > > +CONFIG_OF_BOARD=y > > > > > > To use firmware provided Device Tree. But that should not affect > > > > > > the mmc > > > > > behavior too much, I think. > > > > > > > > > > I've been booting Fedora fine on a RPi4 BUT there's issues with the > > > > > display > > > > > turning off [1] when the accelerated display modules load > > > > > (vc4) as a result of this patch set. Can you confirm if that's the > > > > > same problem > > > > > you're seeing? > > > > > > > > No, that's not my problem. My issue is grub was not loaded by u-boot > > > > from uSD. > > > > It seems more like Simon's problem: > > > > https://lists.denx.de/pipermail/u-boot/2023-October/533162.html > > > > > > > > @Simon, can you check if the patch below fixes your boot problem on > > > > RPi4, please? > > > > > > This has been reported at least twice before. There is a fix [2] which is > > > in my queue to apply. > > > > Looking at that patch it scans the first 3 devices, how does it handle > > non storage devices like SDIO WiFi modules? It shouldn't be trying to > > scan those. > > And in the case of the RPi the other enabled SDHCI interface is the > WiFi, why would we even be trying to boot off a non storage interface, > something here just feels broken/wrong in general. > > The patch does make it work with pure upstream, and I'm not sure why > the Fedora build boots it fine out of the box, but the patch just > feels like it's hacking around some other underlying problem with > bootstd, we didn't have this problem with the previous method and > trying to boot off non storage interfaces feels like it could cause > other problems.
Does U-Boot assume that any SDHCI interface holds storage? Does it use a different compatible string for WiFi? The call to bootdev_setup_for_sibling_blk() in mmc_bind() is what sets up the bootdev, so I suppose there could be a condition there. Having said that, I doubt it would cause any problems. If your comment is about my patch, then could you please reply there, to avoid confusion? Regards, Simon
