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