U-Boot 2023.10 does not boot from uSD on RPi4

[Simon Glass]

Hi Peter,

On Fri, 13 Oct 2023 at 09:22, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet <Guillaume.Gardet at arm.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Peter Robinson <pbrobinson at gmail.com>
> > > > > Sent: Tuesday, October 10, 2023 12:22 PM
> > > > > To: Guillaume Gardet <Guillaume.Gardet at arm.com>
> > > > > Cc: mbrugger at suse.com; Ivan Ivanov <ivan.ivanov at suse.com>; Simon Glass
> > > > > <sjg at chromium.org>; u-boot at 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.Gardet at 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