[PATCH] arm: rpi: explicitly enumerate mmc boot targets
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
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-sj...
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-sj...
Thanks, Ben
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-sj...
Thanks, Ben
Regards, Simon
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?
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.
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.
participants (3)
-
Ben Wolsieffer -
Peter Robinson -
Simon Glass