[PATCH 1/2] rockchip: rk3399: fix incorrect boot-device in u-boot, spl-boot-device

From: Quentin Schulz quentin.schulz@theobroma-systems.com
On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console: MMC: mmc@fe320000: 1, mmc@fe330000: 0
In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and BOOT_DEVICE_MMC2 for mmc1 (SD card).
Since the SD card controller is at mmc@fe320000, it should be associated with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.
Let's fix that by swapping the two BOOT_DEVICEs.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com --- arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 691d69dc59..f280cb1dbf 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -180,8 +180,8 @@ const char *spl_decode_boot_device(u32 boot_device) u32 boot_device; const char *ofpath; } spl_boot_devices_tbl[] = { - { BOOT_DEVICE_MMC1, "/mmc@fe320000" }, - { BOOT_DEVICE_MMC2, "/mmc@fe330000" }, + { BOOT_DEVICE_MMC2, "/mmc@fe320000" }, + { BOOT_DEVICE_MMC1, "/mmc@fe330000" }, { BOOT_DEVICE_SPI, "/spi@ff1d0000" }, };

From: Quentin Schulz quentin.schulz@theobroma-systems.com
While technically not a bug, let's have some consistency in paths returned by u-boot,spl-boot-order look-up and the one saved in u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices node paths.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com --- arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index f280cb1dbf..7147dc09f5 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device) } spl_boot_devices_tbl[] = { { BOOT_DEVICE_MMC2, "/mmc@fe320000" }, { BOOT_DEVICE_MMC1, "/mmc@fe330000" }, - { BOOT_DEVICE_SPI, "/spi@ff1d0000" }, + { BOOT_DEVICE_SPI, "/spi@ff1d0000/flash@0" }, };
for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)

El Fri, Jul 15, 2022 at 05:15:52PM +0200, Quentin Schulz deia:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
While technically not a bug, let's have some consistency in paths returned by u-boot,spl-boot-order look-up and the one saved in u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices node paths.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Tested on a Rock-Pi-4B and didn't see any regression. Tested-by: Xavier Drudis Ferran xdrudis@tinet.cat Reviewed-by: Xavier Drudis Ferran xdrudis@tinet.cat
arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index f280cb1dbf..7147dc09f5 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device) } spl_boot_devices_tbl[] = { { BOOT_DEVICE_MMC2, "/mmc@fe320000" }, { BOOT_DEVICE_MMC1, "/mmc@fe330000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000/flash@0" },
};
for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)
-- 2.36.1

Hi all,
Gentle ping on the series.
Cheers, Quentin
On 7/18/22 23:12, Xavier Drudis Ferran wrote:
El Fri, Jul 15, 2022 at 05:15:52PM +0200, Quentin Schulz deia:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
While technically not a bug, let's have some consistency in paths returned by u-boot,spl-boot-order look-up and the one saved in u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices node paths.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Tested on a Rock-Pi-4B and didn't see any regression. Tested-by: Xavier Drudis Ferran xdrudis@tinet.cat Reviewed-by: Xavier Drudis Ferran xdrudis@tinet.cat
arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index f280cb1dbf..7147dc09f5 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device) } spl_boot_devices_tbl[] = { { BOOT_DEVICE_MMC2, "/mmc@fe320000" }, { BOOT_DEVICE_MMC1, "/mmc@fe330000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000/flash@0" },
};
for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)
-- 2.36.1

On 2022/7/15 23:15, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
While technically not a bug, let's have some consistency in paths returned by u-boot,spl-boot-order look-up and the one saved in u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices node paths.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index f280cb1dbf..7147dc09f5 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -182,7 +182,7 @@ const char *spl_decode_boot_device(u32 boot_device) } spl_boot_devices_tbl[] = { { BOOT_DEVICE_MMC2, "/mmc@fe320000" }, { BOOT_DEVICE_MMC1, "/mmc@fe330000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000/flash@0" },
};
for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)

El Fri, Jul 15, 2022 at 05:15:51PM +0200, Quentin Schulz deia:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console: MMC: mmc@fe320000: 1, mmc@fe330000: 0
In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and BOOT_DEVICE_MMC2 for mmc1 (SD card).
Since the SD card controller is at mmc@fe320000, it should be associated with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.
Let's fix that by swapping the two BOOT_DEVICEs.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com
There's a thread here on what the proper naming would be https://lists.denx.de/pipermail/u-boot/2022-July/489155.html
I agree it's not been consistent, and I'd do it like in this patch, but I don't feel strongly about any option nor pretend to stop any discussion.
Tested on a Rock-Pi-4B and didn't see any regression. Tested-by: Xavier Drudis Ferran xdrudis@tinet.cat
arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 691d69dc59..f280cb1dbf 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -180,8 +180,8 @@ const char *spl_decode_boot_device(u32 boot_device) u32 boot_device; const char *ofpath; } spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe320000" },
{ BOOT_DEVICE_MMC2, "/mmc@fe330000" },
{ BOOT_DEVICE_MMC2, "/mmc@fe320000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000" }, };{ BOOT_DEVICE_MMC1, "/mmc@fe330000" },
-- 2.36.1

On 2022/7/15 23:15, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console: MMC: mmc@fe320000: 1, mmc@fe330000: 0
In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and BOOT_DEVICE_MMC2 for mmc1 (SD card).
Since the SD card controller is at mmc@fe320000, it should be associated with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.
Let's fix that by swapping the two BOOT_DEVICEs.
Cc: Quentin Schulz foss+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@theobroma-systems.com
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 691d69dc59..f280cb1dbf 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -180,8 +180,8 @@ const char *spl_decode_boot_device(u32 boot_device) u32 boot_device; const char *ofpath; } spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe320000" },
{ BOOT_DEVICE_MMC2, "/mmc@fe330000" },
{ BOOT_DEVICE_MMC2, "/mmc@fe320000" },
{ BOOT_DEVICE_SPI, "/spi@ff1d0000" }, };{ BOOT_DEVICE_MMC1, "/mmc@fe330000" },
participants (4)
-
Kever Yang
-
Quentin Schulz
-
Quentin Schulz
-
Xavier Drudis Ferran