U-Boot 2023.10 does not boot from uSD on RPi4

[Peter Robinson]

On Fri, Oct 13, 2023 at 6:48 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Oct 13, 2023 at 05:22:03PM +0100, Peter Robinson 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.
>
> 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

Well that's not entirely true in the case of mmc/sdhci, we know what
devices could be storage, such as when a device is a mSD or eMMC or a
wifi interface, those don't change from boot to boot, a SDHCI
interface on one boot is not mysteriously going to become a emmc
storage unit the next boot.

> 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.

It has caused issues and it causes bug reports from users which is an
issue for me as a maintainer as it wastes my time. In short it's not a
great user experience.

Overall the last few U-Boot releases have been a nightmare from my
PoV, I have spent *all* my available time for upstream U-Boot dealing
with regressions.

In the case of the RPi I currently have 3 issues, 1) display 2) mSD 3)
USB (that Ivan has also mentioned). The 3 of these together make
things very hard to bisect and I am struggling. I also have 3 other
devices with issues I'm trying to debug for the Fedora release, and
the asahi people have also reported [1] regressions in their fork. I
honestly regret applying the bootstd patches.

When even Simon [2] is losing track of things I think we need to
change approach, the problems here upstream are nearly breaking me and
for Fedora I am now considering just forking U-Boot and cherry picking
the patches from upstream we need for particular devices and features.
It's absolutely not something I want to do but I feel it's getting to
the point I need to do it for the Fedora users and my sanity.

I like the concept of bootstd and other features but the quantity of
patches, and sometimes other series of change for changes sake, where
the testing is clearly either not there, or is relying on "it works on
CI" [3] (and other examples) and is clearly not tested on real HW
makes some of the churn hugely problematic, similarly the applying of
patches when there's been opposition and push back for the sake of it
(eg NFSv1 patch) as is things like force enabling people's pet
projects (looking at VBE here) where there's no actual real world
users and real security ramifications (alternate unaudited boot
methods of devices) also adds to my thought process for forking.

I feel we as a project need to have a proper discussion about these things.

Peter

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2244305#c6
[2] https://lists.denx.de/pipermail/u-boot/2023-October/534348.html
[3] https://lists.denx.de/pipermail/u-boot/2023-October/534442.html