Re: U-Boot 2023.10 does not boot from uSD on RPi4
Apologies for the late public reply. On Thu, Oct 19, 2023 at 03:06:48PM +0100, Peter Robinson wrote: > On Fri, Oct 13, 2023 at 6:48 PM Tom Rini 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 > > > wrote: > > > > > > > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Peter Robinson > > > > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > > > > To: Guillaume Gardet > > > > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon > > > > > > > Glass > > > > > > > ; 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 > > > > > > > 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. Getting in to specifics here, I believe one of the issues is that RPi 3 uses SDHCI #1 for WiFi and #0 for micro SD card and RPi 4 is the other way. So rpi_arm64 U-Boot binaries have to talk at both devices to see what's there. We _should_ be doing this in such a way that we discover both quickly enough and safely enough
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi, On Thu, 2023-10-19 at 08:32 -0600, Simon Glass wrote: > > > > > > > > I am afraid we still have a boot issue. This time device can not boot > > > > from USB. > > > > Device boot order was changed to USB first then uSD. uSD card is > > > > removed. > > > > > > > > Please see [1] attachment #870321 for boot log details. > > > > > > > > I have not invested time to debug this, still. > > > > > > Thanks for the info. Is this using 'boot_targets=mmc usb pxe dhcp'? > > > > > > > Yes. "boot_targets=mmc usb pxe dhcp". Full environment added to the bug. > > > > https://bugzilla.suse.com/show_bug.cgi?id=1216036 > > OK thank you, I will take a look. > > I wonder if there is a way of testing pending patches, or do they need > to be applied before they can be tested in your systems? I am not sure what do you mean here. openSUSE uses this [1] project on Open Build Service to build installable packages. As you can see there are few patches on top of u-boot-2023.10 release including [2]. What I can do is to build new package with any proposed patch on top of last release. Of course I can also build the U-Boot and just copy binary to the board. In other words I could test any proposed patch :-) Regards, Ivan [1] https://build.opensuse.org/package/show/hardware:boot/u-boot [2] bootstd: Scan all bootdevs in a boot_targets entry
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Thu, 2023-10-19 at 08:00 -0600, Simon Glass wrote: > > > > > > [2] > > > https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > > > > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > > > > > > > 'git bisect' points to: > > > > > > ** > > > > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > > > > Author: Simon Glass > > > > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > > > > > > > arm: rpi: Switch to standard boot > > > > > > > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > > > > > > > We don't need to specify the mmc devices individually, since > > > > > > they are > > > > > > used in order from 0 to 2, and standard boot uses that order > > > > > > anyway. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > ** > > > > > > > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on > > > > > > RPi3 nor RPi > > > > > Zero 2 W): > > > > > > ** > > > > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > > > > --- a/board/raspberrypi/rpi/rpi.env > > > > > > +++ b/board/raspberrypi/rpi/rpi.env > > > > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > > > > fdt_addr_r=0x0260 > > > > > > ramdisk_addr_r=0x0270 > > > > > > > > > > > > -boot_targets=mmc usb pxe dhcp > > > > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > > > > ** > > > > > > > > > > > > So, the comment from Simon " We don't need to specify the mmc > > > > > > devices > > > > > individually, since they are used in order from 0 to 2, and standard > > > > > boot uses that > > > > > order anyway" seems wrong for the RPi4 case. > > > > > > > > > > I am afraid we still have a boot issue. This time device can not boot from > > USB. > > Device boot order was changed to USB first then uSD. uSD card is removed. > > > > Please see [1] attachment #870321 for boot log details. > > > > I have not invested time to debug this, still. > > Thanks for the info. Is this using 'boot_targets=mmc usb pxe dhcp'? > Yes. "boot_targets=mmc usb pxe dhcp". Full environment added to the bug. https://bugzilla.suse.com/show_bug.cgi?id=1216036
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi Ivan, On Thu, 19 Oct 2023 at 08:29, Ivan Ivanov wrote: > > On Thu, 2023-10-19 at 08:00 -0600, Simon Glass wrote: > > > > > > > > [2] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > > > > > > > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > > > > > > > > > 'git bisect' points to: > > > > > > > ** > > > > > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > > > > > Author: Simon Glass > > > > > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > > > > > > > > > arm: rpi: Switch to standard boot > > > > > > > > > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > > > > > > > > > We don't need to specify the mmc devices individually, since > > > > > > > they are > > > > > > > used in order from 0 to 2, and standard boot uses that order > > > > > > > anyway. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > ** > > > > > > > > > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested > > > > > > > on RPi3 nor RPi > > > > > > Zero 2 W): > > > > > > > ** > > > > > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > > > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 > > > > > > > 100644 > > > > > > > --- a/board/raspberrypi/rpi/rpi.env > > > > > > > +++ b/board/raspberrypi/rpi/rpi.env > > > > > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > > > > > fdt_addr_r=0x0260 > > > > > > > ramdisk_addr_r=0x0270 > > > > > > > > > > > > > > -boot_targets=mmc usb pxe dhcp > > > > > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > > > > > ** > > > > > > > > > > > > > > So, the comment from Simon " We don't need to specify the mmc > > > > > > > devices > > > > > > individually, since they are used in order from 0 to 2, and > > > > > > standard boot uses that > > > > > > order anyway" seems wrong for the RPi4 case. > > > > > > > > > > > > > I am afraid we still have a boot issue. This time device can not boot > > > from USB. > > > Device boot order was changed to USB first then uSD. uSD card is removed. > > > > > > Please see [1] attachment #870321 for boot log details. > > > > > > I have not invested time to debug this, still. > > > > Thanks for the info. Is this using 'boot_targets=mmc usb pxe dhcp'? > > > > Yes. "boot_targets=mmc usb pxe dhcp". Full environment added to the bug. > > https://bugzilla.suse.com/show_bug.cgi?id=1216036 OK thank you, I will take a look. I wonder if there is a way of testing pending patches, or do they need to be applied before they can be tested in your systems? Regards, Simon
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Fri, Oct 13, 2023 at 6:48 PM Tom Rini 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 wrote: > > > > > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > > > > wrote: > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Peter Robinson > > > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > > > To: Guillaume Gardet > > > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon > > > > > > Glass > > > > > > ; 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 > > > > > > 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
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi Ivan, On Thu, 19 Oct 2023 at 02:59, Ivan Ivanov wrote: > > > Hi, > > Sorry I can't find mail thread regarding patch itself, so using this one: > > On Fri, 2023-10-13 at 10:08 +, Guillaume Gardet wrote: > > > > > > > > Hi, > > > > Indeed, your patch [2] fixes my boot problem. > > > > > > > > > > > [2] > > https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > > > > > 'git bisect' points to: > > > > > ** > > > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > > > Author: Simon Glass > > > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > > > > > arm: rpi: Switch to standard boot > > > > > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > > > > > We don't need to specify the mmc devices individually, since > > > > > they are > > > > > used in order from 0 to 2, and standard boot uses that order > > > > > anyway. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > ** > > > > > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on > > > > > RPi3 nor RPi > > > > Zero 2 W): > > > > > ** > > > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > > > --- a/board/raspberrypi/rpi/rpi.env > > > > > +++ b/board/raspberrypi/rpi/rpi.env > > > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > > > fdt_addr_r=0x0260 > > > > > ramdisk_addr_r=0x0270 > > > > > > > > > > -boot_targets=mmc usb pxe dhcp > > > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > > > ** > > > > > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > > > individually, since they are used in order from 0 to 2, and standard > > > > boot uses that > > > > order anyway" seems wrong for the RPi4 case. > > > > > > > I am afraid we still have a boot issue. This time device can not boot from > USB. > Device boot order was changed to USB first then uSD. uSD card is removed. > > Please see [1] attachment #870321 for boot log details. > > I have not invested time to debug this, still. Thanks for the info. Is this using 'boot_targets=mmc usb pxe dhcp'? We can revert the patch, perhaps, but I'd like to understand why it is failing. Regards, Simon
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi, Sorry I can't find mail thread regarding patch itself, so using this one: On Fri, 2023-10-13 at 10:08 +, Guillaume Gardet wrote: > > > > Hi, > > Indeed, your patch [2] fixes my boot problem. > > > > [2] > https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > > > 'git bisect' points to: > > > > ** > > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > > Author: Simon Glass > > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > > > arm: rpi: Switch to standard boot > > > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > > > We don't need to specify the mmc devices individually, since they > > > > are > > > > used in order from 0 to 2, and standard boot uses that order > > > > anyway. > > > > > > > > Signed-off-by: Simon Glass > > > > ** > > > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 > > > > nor RPi > > > Zero 2 W): > > > > ** > > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > > --- a/board/raspberrypi/rpi/rpi.env > > > > +++ b/board/raspberrypi/rpi/rpi.env > > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > > fdt_addr_r=0x0260 > > > > ramdisk_addr_r=0x0270 > > > > > > > > -boot_targets=mmc usb pxe dhcp > > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > > ** > > > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > > individually, since they are used in order from 0 to 2, and standard boot > > > uses that > > > order anyway" seems wrong for the RPi4 case. > > > > I am afraid we still have a boot issue. This time device can not boot from USB. Device boot order was changed to USB first then uSD. uSD card is removed. Please see [1] attachment #870321 for boot log details. I have not invested time to debug this, still. Regards, Ivan [1] https://bugzilla.suse.com/show_bug.cgi?id=1216036
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Fri, Oct 13, 2023 at 05:22:03PM +0100, Peter Robinson wrote: > On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson wrote: > > > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > > > > > Hi, > > > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Peter Robinson > > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > > To: Guillaume Gardet > > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > > > > ; 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 > > > > > 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
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi Peter, On Fri, 13 Oct 2023 at 09:22, Peter Robinson wrote: > > On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson wrote: > > > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > > > > > Hi, > > > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Peter Robinson > > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > > To: Guillaume Gardet > > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > > > > ; 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 > > > > > 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
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson wrote: > > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > > > Hi, > > > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Peter Robinson > > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > > To: Guillaume Gardet > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > > > ; 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 > > > > 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.
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Tue, Oct 10, 2023 at 3:58 PM Simon Glass wrote: > > Hi, > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet > wrote: > > > > > > > > > -Original Message- > > > From: Peter Robinson > > > Sent: Tuesday, October 10, 2023 12:22 PM > > > To: Guillaume Gardet > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > > ; 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 > > > 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. > Regarding the display problem, I got my rpi4 running again and Fedora > installed, but I won't get back to it until the end of the week as I'm at > osfc. > > Regards, > Simon > > > > > Thanks, > > Guillaume > > > > [2] > https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > > > 'git bisect' points to: > > > > ** > > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > > Author: Simon Glass > > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > > > arm: rpi: Switch to standard boot > > > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > > > We don't need to specify the mmc devices individually, since they > > > > are > > > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > > > > > Signed-off-by: Simon Glass > > > > ** > > > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 > > > > nor RPi > > > Zero 2 W): > > > > ** > > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > > --- a/board/raspberrypi/rpi/rpi.env > > > > +++ b/board/raspberrypi/rpi/rpi.env > > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > > fdt_addr_r=0x0260 > > > > ramdisk_addr_r=0x0270 > > > > > > > > -boot_targets=mmc usb pxe dhcp > > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > > ** > > > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > > individually, since they are used in order from 0 to 2, and standard boot > > > uses that > > > order anyway" seems wrong for the RPi4 case. > > > > > > > > Cheers, > > > > Guillaume > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > > confidential and may also be privileged. If you are not the intended > > > recipient, > > > please notify the sender immediately and do not disclose the contents to > > > any > > > other person, use it for any purpose, or store or copy the information in > > > any > > > medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > > recipient, please notify the sender immediately and do not disclose the > > contents to any other person, use it for any purpose, or store or copy the > > information in any medium. Thank you.
RE: U-Boot 2023.10 does not boot from uSD on RPi4
Hi, Indeed, your patch [2] fixes my boot problem. Thanks, Guillaume From: Simon Glass Sent: Tuesday, October 10, 2023 4:58 PM To: Guillaume Gardet Cc: Peter Robinson ; Matthias Brugger ; Ivan Ivanov ; U-Boot Mailing List Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4 Hi, On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet mailto:guillaume.gar...@arm.com>> wrote: > > > > > -Original Message- > > From: Peter Robinson mailto:pbrobin...@gmail.com>> > > Sent: Tuesday, October 10, 2023 12:22 PM > > To: Guillaume Gardet > > mailto:guillaume.gar...@arm.com>> > > Cc: mbrug...@suse.com<mailto:mbrug...@suse.com>; Ivan Ivanov > > mailto:ivan.iva...@suse.com>>; Simon Glass > > mailto:s...@chromium.org>>; > > u-boot@lists.denx.de<mailto: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 > > mailto: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. Regarding the display problem, I got my rpi4 running again and Fedora installed, but I won't get back to it until the end of the week as I'm at osfc. Regards, Simon > > Thanks, > Guillaume > [2] https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > 'git bisect' points to: > > > ** > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > Author: Simon Glass mailto:s...@chromium.org>> > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > arm: rpi: Switch to standard boot > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > We don't need to specify the mmc devices individually, since they are > > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > > > Signed-off-by: Simon Glass > > > mailto:s...@chromium.org>> > > > ** > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 > > > nor RPi > > Zero 2 W): > > > ** > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > --- a/board/raspberrypi/rpi/rpi.env > > > +++ b/board/raspberrypi/rpi/rpi.env > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > fdt_addr_r=0x0260 > > > ramdisk_addr_r=0x0270 > > > > > > -boot_targets=mmc usb pxe dhcp > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > ** > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > individually, since they are used in order from 0 to 2, and standard boot > > uses that > > order anyway" seems wrong for the RPi4 case. > > > > > > Cheers, > > > Guillaume > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > > recipient, > > please notify the sender immediately and do not disclose the contents to any > > other person, use it for any purpose, or store or copy the information in > > any > > medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: U-Boot 2023.10 does not boot from uSD on RPi4
Hi, On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet wrote: > > > > > -Original Message- > > From: Peter Robinson > > Sent: Tuesday, October 10, 2023 12:22 PM > > To: Guillaume Gardet > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > > ; 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 > > 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. Regarding the display problem, I got my rpi4 running again and Fedora installed, but I won't get back to it until the end of the week as I'm at osfc. Regards, Simon > > Thanks, > Guillaume > [2] https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/ > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > > > 'git bisect' points to: > > > ** > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > > Author: Simon Glass > > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > > > arm: rpi: Switch to standard boot > > > > > > Drop use of the distro scripts and use standard boot instead. > > > > > > We don't need to specify the mmc devices individually, since they are > > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > > > Signed-off-by: Simon Glass > > > ** > > > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor RPi > > Zero 2 W): > > > ** > > > diff --git a/board/raspberrypi/rpi/rpi.env > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > > --- a/board/raspberrypi/rpi/rpi.env > > > +++ b/board/raspberrypi/rpi/rpi.env > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > > fdt_addr_r=0x0260 > > > ramdisk_addr_r=0x0270 > > > > > > -boot_targets=mmc usb pxe dhcp > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > > ** > > > > > > So, the comment from Simon " We don't need to specify the mmc devices > > individually, since they are used in order from 0 to 2, and standard boot uses that > > order anyway" seems wrong for the RPi4 case. > > > > > > Cheers, > > > Guillaume > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended recipient, > > please notify the sender immediately and do not disclose the contents to any > > other person, use it for any purpose, or store or copy the information in any > > medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
RE: U-Boot 2023.10 does not boot from uSD on RPi4
> -Original Message- > From: Peter Robinson > Sent: Tuesday, October 10, 2023 12:22 PM > To: Guillaume Gardet > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass > ; 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 > 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? Thanks, Guillaume > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > > > 'git bisect' points to: > > ** > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > > Author: Simon Glass > > Date: Thu Jul 27 15:54:28 2023 -0600 > > > > arm: rpi: Switch to standard boot > > > > Drop use of the distro scripts and use standard boot instead. > > > > We don't need to specify the mmc devices individually, since they are > > used in order from 0 to 2, and standard boot uses that order anyway. > > > > Signed-off-by: Simon Glass > > ** > > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor > > RPi > Zero 2 W): > > ** > > diff --git a/board/raspberrypi/rpi/rpi.env > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644 > > --- a/board/raspberrypi/rpi/rpi.env > > +++ b/board/raspberrypi/rpi/rpi.env > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > > fdt_addr_r=0x0260 > > ramdisk_addr_r=0x0270 > > > > -boot_targets=mmc usb pxe dhcp > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > > ** > > > > So, the comment from Simon " We don't need to specify the mmc devices > individually, since they are used in order from 0 to 2, and standard boot > uses that > order anyway" seems wrong for the RPi4 case. > > > > Cheers, > > Guillaume > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: U-Boot 2023.10 does not boot from uSD on RPi4
On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet 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? [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html > 'git bisect' points to: > ** > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9 > Author: Simon Glass > Date: Thu Jul 27 15:54:28 2023 -0600 > > arm: rpi: Switch to standard boot > > Drop use of the distro scripts and use standard boot instead. > > We don't need to specify the mmc devices individually, since they are > used in order from 0 to 2, and standard boot uses that order anyway. > > Signed-off-by: Simon Glass > ** > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 nor > RPi Zero 2 W): > ** > diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env > index 30228285ed..02210b97b5 100644 > --- a/board/raspberrypi/rpi/rpi.env > +++ b/board/raspberrypi/rpi/rpi.env > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250 > fdt_addr_r=0x0260 > ramdisk_addr_r=0x0270 > > -boot_targets=mmc usb pxe dhcp > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp > ** > > So, the comment from Simon " We don't need to specify the mmc devices > individually, since they are used in order from 0 to 2, and standard boot > uses that order anyway" seems wrong for the RPi4 case. > > Cheers, > Guillaume > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.
