diff mbox series

arm: rpi: explicitly enumerate mmc boot targets

Message ID 20231007155535.1699567-1-benwolsieffer@gmail.com
State New
Delegated to: Peter Robinson
Headers show
Series arm: rpi: explicitly enumerate mmc boot targets | expand

Commit Message

Ben Wolsieffer Oct. 7, 2023, 3:55 p.m. UTC
Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
fail to boot. c771e5b explains this approach as follows:

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

In practice, U-Boot first attempts to boot from the unconnected mmc1
interface, and, when this fails, moves on to attempt the USB and network
boot targets rather than trying mmc0.

This patch explicitly enumerates the mmc interfaces, causing each to be
attempted in turn. This matches what is done on other boards, and allows
the system to boot successfully.

Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
---
 board/raspberrypi/rpi/rpi.env | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Simon Glass Oct. 7, 2023, 8:18 p.m. UTC | #1
Hi Ben,

On Sat, 7 Oct 2023 at 09:55, Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
>
> Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> fail to boot. c771e5b explains this approach as follows:
>
> > 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.
>
> In practice, U-Boot first attempts to boot from the unconnected mmc1
> interface, and, when this fails, moves on to attempt the USB and network
> boot targets rather than trying mmc0.
>
> This patch explicitly enumerates the mmc interfaces, causing each to be
> attempted in turn. This matches what is done on other boards, and allows
> the system to boot successfully.
>
> Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> ---
>  board/raspberrypi/rpi/rpi.env | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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
> --
> 2.42.0
>

Does this patch help? [1]. Alternatively, if you just remove that
variable entirely, does it do the right thing?

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-sjg@chromium.org/
Peter Robinson Oct. 8, 2023, 6:21 p.m. UTC | #2
On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
>
> Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> fail to boot. c771e5b explains this approach as follows:
>
> > 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.
>
> In practice, U-Boot first attempts to boot from the unconnected mmc1
> interface, and, when this fails, moves on to attempt the USB and network
> boot targets rather than trying mmc0.

Really? It shouldn't be enumerating it if it's not defined in device
tree, I've not seen this in my testing.

> This patch explicitly enumerates the mmc interfaces, causing each to be
> attempted in turn. This matches what is done on other boards, and allows
> the system to boot successfully.
>
> Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> ---
>  board/raspberrypi/rpi/rpi.env | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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

Why are you adding mmc1 and mmc2 if they're not connected?
Ben Wolsieffer Oct. 8, 2023, 9:55 p.m. UTC | #3
Hi Simon,

On Sat, Oct 07, 2023 at 02:18:48PM -0600, Simon Glass wrote:
> Hi Ben,
> 
> On Sat, 7 Oct 2023 at 09:55, Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
> >
> > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > fail to boot. c771e5b explains this approach as follows:
> >
> > > 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.
> >
> > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > interface, and, when this fails, moves on to attempt the USB and network
> > boot targets rather than trying mmc0.
> >
> > This patch explicitly enumerates the mmc interfaces, causing each to be
> > attempted in turn. This matches what is done on other boards, and allows
> > the system to boot successfully.
> >
> > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> > ---
> >  board/raspberrypi/rpi/rpi.env | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Does this patch help? [1]. Alternatively, if you just remove that
> variable entirely, does it do the right thing?

Yes, trying either of those suggestions makes it work correctly.

> 
> Regards,
> Simon
> 
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-sjg@chromium.org/


Thanks, Ben
Ben Wolsieffer Oct. 8, 2023, 10:32 p.m. UTC | #4
Hi Peter,

On Sun, Oct 08, 2023 at 07:21:57PM +0100, Peter Robinson wrote:
> On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
> >
> > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > fail to boot. c771e5b explains this approach as follows:
> >
> > > 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.
> >
> > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > interface, and, when this fails, moves on to attempt the USB and network
> > boot targets rather than trying mmc0.
> 
> Really? It shouldn't be enumerating it if it's not defined in device
> tree, I've not seen this in my testing.

It does seem odd, but U-Boot definitely sees two MMC interfaces:

U-Boot> mmc list
mmcnr@7e300000: 1
mmc@7e340000: 0 (SD)

> 
> > This patch explicitly enumerates the mmc interfaces, causing each to be
> > attempted in turn. This matches what is done on other boards, and allows
> > the system to boot successfully.
> >
> > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> > ---
> >  board/raspberrypi/rpi/rpi.env | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > 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
> 
> Why are you adding mmc1 and mmc2 if they're not connected?

I was trying to match the old distro boot behavior, which had three MMC
interfaces listed.
Simon Glass Oct. 9, 2023, 5:56 p.m. UTC | #5
Hi Ben,

On Sun, 8 Oct 2023 at 15:55, Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
>
> Hi Simon,
>
> On Sat, Oct 07, 2023 at 02:18:48PM -0600, Simon Glass wrote:
> > Hi Ben,
> >
> > On Sat, 7 Oct 2023 at 09:55, Ben Wolsieffer <benwolsieffer@gmail.com>
wrote:
> > >
> > > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > > fail to boot. c771e5b explains this approach as follows:
> > >
> > > > 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.
> > >
> > > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > > interface, and, when this fails, moves on to attempt the USB and
network
> > > boot targets rather than trying mmc0.
> > >
> > > This patch explicitly enumerates the mmc interfaces, causing each to
be
> > > attempted in turn. This matches what is done on other boards, and
allows
> > > the system to boot successfully.
> > >
> > > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > > Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> > > ---
> > >  board/raspberrypi/rpi/rpi.env | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> >
> > Does this patch help? [1]. Alternatively, if you just remove that
> > variable entirely, does it do the right thing?
>
> Yes, trying either of those suggestions makes it work correctly.

Thank you for testing this

In that case, I would rather that [1] since it should fix it for all
boards. If you want to send a patch to drop boot_targets, please do and
I'll leave that to Peter.

>
> >
> > Regards,
> > Simon
> >
> > [1]
https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-sjg@chromium.org/
>
>
> Thanks, Ben

Regards,
Simon
Peter Robinson Oct. 10, 2023, 10:39 a.m. UTC | #6
On Sun, Oct 8, 2023 at 11:32 PM Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
>
> Hi Peter,
>
> On Sun, Oct 08, 2023 at 07:21:57PM +0100, Peter Robinson wrote:
> > On Sat, Oct 7, 2023 at 4:55 PM Ben Wolsieffer <benwolsieffer@gmail.com> wrote:
> > >
> > > Using the unqualified "mmc" boot target causes the Raspberry Pi 4 to
> > > fail to boot. c771e5b explains this approach as follows:
> > >
> > > > 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.
> > >
> > > In practice, U-Boot first attempts to boot from the unconnected mmc1
> > > interface, and, when this fails, moves on to attempt the USB and network
> > > boot targets rather than trying mmc0.
> >
> > Really? It shouldn't be enumerating it if it's not defined in device
> > tree, I've not seen this in my testing.
>
> It does seem odd, but U-Boot definitely sees two MMC interfaces:
>
> U-Boot> mmc list
> mmcnr@7e300000: 1
> mmc@7e340000: 0 (SD)

The WiFi interface is connected by SDHCI/SDIO which AFAICT is the
first interface.

> >
> > > This patch explicitly enumerates the mmc interfaces, causing each to be
> > > attempted in turn. This matches what is done on other boards, and allows
> > > the system to boot successfully.
> > >
> > > Fixes: c771e5b8c2 ("arm: rpi: Switch to standard boot")
> > > Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
> > > ---
> > >  board/raspberrypi/rpi/rpi.env | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > 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
> >
> > Why are you adding mmc1 and mmc2 if they're not connected?
>
> I was trying to match the old distro boot behavior, which had three MMC
> interfaces listed.
diff mbox series

Patch

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