On Fri, Oct 13, 2023 at 05:22:03PM +0100, Peter Robinson 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.
I think the answer here is that we're doing the best we can given that we just don't know until run time what we have. In the case where sdhci is something other than storage, we get as far as asking "are you a block device?" which then fails when sdhci is a WiFi an not an eMMC. This does mean the user could notice "Card did not respond to voltage select! : -110" being printed, and I don't know if we should do anything about that (it's a handy message when your uSD isn't fully inserted, etc). But since we (can) support everything on a single build, we just have to figure it out at run time. -- Tom
signature.asc
Description: PGP signature
