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.

> 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 <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 <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=0x02500000
> > > >  fdt_addr_r=0x02600000
> > > >  ramdisk_addr_r=0x02700000
> > > >
> > > > -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.

Reply via email to