[U-Boot] [PATCH 0/4] mmc: sunxi: index hack removal
Hi,
Here is an attempt at removing the hack in the sunxi code to switch the MMC indices depending on the boot device.
It's based on Siarhei's suggestion to go through an environment variable set by the code, and then having a script in our default bootcmd to change the boot order in order to always favour the boot device, instead of always picking the external MMC first.
Let me know what you think, Maxime
Maxime Ripard (4): mmc: sunxi: fix legacy MMC initialisation arm: sunxi: compile spl_boot_device even for U-Boot sunxi: Use spl_boot_device sunxi: Remove the MMC index hack
arch/arm/mach-sunxi/board.c | 4 +--- board/sunxi/board.c | 26 +++++++++++--------------- drivers/mmc/sunxi_mmc.c | 2 +- include/configs/sunxi-common.h | 36 ++++++++++++++++++++++++++++++------ 4 files changed, 43 insertions(+), 25 deletions(-)
The driver-model rework changed, among other things, the way the private data were moved around. It now uses the private field in the struct mmc.
However, the mmc_create argument was changed in the process to always pass the array we used to have to store our private structures.
The basically means that all the MMC driver instances will now have the private data of the first instance, which obviously doesn't work very well.
Pass the proper pointer to mmc_create.
Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly") Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- drivers/mmc/sunxi_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 588574fab6a9..30f1f76e9f8c 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -498,7 +498,7 @@ struct mmc *sunxi_mmc_init(int sdc_no) if (ret) return NULL;
- return mmc_create(cfg, mmc_host); + return mmc_create(cfg, priv); } #else
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
The driver-model rework changed, among other things, the way the private data were moved around. It now uses the private field in the struct mmc.
However, the mmc_create argument was changed in the process to always pass the array we used to have to store our private structures.
The basically means that all the MMC driver instances will now have the private data of the first instance, which obviously doesn't work very well.
Pass the proper pointer to mmc_create.
Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly") Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Tested-by: Chen-Yu Tsai wens@csie.org
On Thu, Aug 24, 2017 at 8:41 AM, Chen-Yu Tsai wens@csie.org wrote:
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
The driver-model rework changed, among other things, the way the private data were moved around. It now uses the private field in the struct mmc.
However, the mmc_create argument was changed in the process to always pass the array we used to have to store our private structures.
The basically means that all the MMC driver instances will now have the private data of the first instance, which obviously doesn't work very well.
Pass the proper pointer to mmc_create.
Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly") Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Tested-by: Chen-Yu Tsai wens@csie.org
Tested-by: Jagan Teki jagan@openedev.com Reviewed-by: Jagan Teki jagan@openedev.com
thanks!
On Thu, Aug 24, 2017 at 12:20 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Thu, Aug 24, 2017 at 8:41 AM, Chen-Yu Tsai wens@csie.org wrote:
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
The driver-model rework changed, among other things, the way the private data were moved around. It now uses the private field in the struct mmc.
However, the mmc_create argument was changed in the process to always pass the array we used to have to store our private structures.
The basically means that all the MMC driver instances will now have the private data of the first instance, which obviously doesn't work very well.
Pass the proper pointer to mmc_create.
Fixes: 034e226bc77e ("dm: mmc: sunxi: Pass private data around explicitly") Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Tested-by: Chen-Yu Tsai wens@csie.org
Tested-by: Jagan Teki jagan@openedev.com Reviewed-by: Jagan Teki jagan@openedev.com
Applied to u-boot-sunxi/master
thanks!
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- arch/arm/mach-sunxi/board.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 65b1ebd83787..f5e977b4183d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -14,9 +14,7 @@ #include <mmc.h> #include <i2c.h> #include <serial.h> -#ifdef CONFIG_SPL_BUILD #include <spl.h> -#endif #include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/clock.h> @@ -210,7 +208,6 @@ void s_init(void) eth_init_board(); }
-#ifdef CONFIG_SPL_BUILD DECLARE_GLOBAL_DATA_PTR;
/* The sunxi internal brom will try to loader external bootloader @@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; }
+#ifdef CONFIG_SPL_BUILD void board_init_f(ulong dummy) { spl_init();
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Tested-by: Chen-Yu Tsai wens@csie.org
On Wed, Aug 23, 2017 at 5:11 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/mach-sunxi/board.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 65b1ebd83787..f5e977b4183d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -14,9 +14,7 @@ #include <mmc.h> #include <i2c.h> #include <serial.h> -#ifdef CONFIG_SPL_BUILD #include <spl.h> -#endif #include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/clock.h> @@ -210,7 +208,6 @@ void s_init(void) eth_init_board(); }
-#ifdef CONFIG_SPL_BUILD DECLARE_GLOBAL_DATA_PTR;
/* The sunxi internal brom will try to loader external bootloader @@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; }
+#ifdef CONFIG_SPL_BUILD
Based on this, 3/4 is reusing for finding boot device, reusing spl core functions in u-boot proper is not good approach. Better to have some separate function that determine boot source and reuse the same in spl and U-Boot proper.
thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.
Hi Jagan,
On Thu, Aug 24, 2017 at 12:25:24PM +0530, Jagan Teki wrote:
On Wed, Aug 23, 2017 at 5:11 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/mach-sunxi/board.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 65b1ebd83787..f5e977b4183d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -14,9 +14,7 @@ #include <mmc.h> #include <i2c.h> #include <serial.h> -#ifdef CONFIG_SPL_BUILD #include <spl.h> -#endif #include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/clock.h> @@ -210,7 +208,6 @@ void s_init(void) eth_init_board(); }
-#ifdef CONFIG_SPL_BUILD DECLARE_GLOBAL_DATA_PTR;
/* The sunxi internal brom will try to loader external bootloader @@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; }
+#ifdef CONFIG_SPL_BUILD
Based on this, 3/4 is reusing for finding boot device, reusing spl core functions in u-boot proper is not good approach. Better to have some separate function that determine boot source and reuse the same in spl and U-Boot proper.
I'm not sure what you mean here, do you want something like
int sunxi_boot_device() { .... }
#ifdef CONFIG_SPL_BUILD int spl_boot_device() { return sunxi_boot_device(); } #endif
I mean, I could do that, but I don't see the difference. Can you elaborate?
Thanks, Maxime
Hi Maxime,
On Fri, Aug 25, 2017 at 1:32 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi Jagan,
On Thu, Aug 24, 2017 at 12:25:24PM +0530, Jagan Teki wrote:
On Wed, Aug 23, 2017 at 5:11 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/mach-sunxi/board.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 65b1ebd83787..f5e977b4183d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -14,9 +14,7 @@ #include <mmc.h> #include <i2c.h> #include <serial.h> -#ifdef CONFIG_SPL_BUILD #include <spl.h> -#endif #include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/clock.h> @@ -210,7 +208,6 @@ void s_init(void) eth_init_board(); }
-#ifdef CONFIG_SPL_BUILD DECLARE_GLOBAL_DATA_PTR;
/* The sunxi internal brom will try to loader external bootloader @@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; }
+#ifdef CONFIG_SPL_BUILD
Based on this, 3/4 is reusing for finding boot device, reusing spl core functions in u-boot proper is not good approach. Better to have some separate function that determine boot source and reuse the same in spl and U-Boot proper.
I'm not sure what you mean here, do you want something like
int sunxi_boot_device() { .... }
#ifdef CONFIG_SPL_BUILD int spl_boot_device() { return sunxi_boot_device(); } #endif
I mean, I could do that, but I don't see the difference. Can you elaborate?
spl_boot_device is SPL core function so it's better not to call for U-Boot proper instead I recommended to use stub function, anyway that stub look sunxi function so we can use it in both the stages - IMHO.
thanks!
Our current board code duplicates a bit the spl_boot_device logic. Now that we can use that function in the full-flavoured U-Boot, remove that duplication and call the function instead.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- board/sunxi/board.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 800f412b383d..e1d48140878f 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -32,6 +32,7 @@ #include <libfdt.h> #include <nand.h> #include <net.h> +#include <spl.h> #include <sy8106a.h> #include <asm/setup.h>
@@ -720,11 +721,14 @@ static void setup_environment(const void *fdt) int misc_init_r(void) { __maybe_unused int ret; + uint boot;
setenv("fel_booted", NULL); setenv("fel_scriptaddr", NULL); + + boot = spl_boot_device(); /* determine if we are running in FEL mode */ - if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */ + if (boot == BOOT_DEVICE_BOARD) { setenv("fel_booted", "1"); parse_spl_header(SPL_ADDR); }
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Our current board code duplicates a bit the spl_boot_device logic. Now that we can use that function in the full-flavoured U-Boot, remove that duplication and call the function instead.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
board/sunxi/board.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 800f412b383d..e1d48140878f 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -32,6 +32,7 @@ #include <libfdt.h> #include <nand.h> #include <net.h> +#include <spl.h> #include <sy8106a.h> #include <asm/setup.h>
@@ -720,11 +721,14 @@ static void setup_environment(const void *fdt) int misc_init_r(void) { __maybe_unused int ret;
uint boot; setenv("fel_booted", NULL); setenv("fel_scriptaddr", NULL);
This doesn't apply on master due to commit 382bee57f19b ("env: Rename setenv() to env_set()")
ChenYu
boot = spl_boot_device(); /* determine if we are running in FEL mode */
if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
if (boot == BOOT_DEVICE_BOARD) { setenv("fel_booted", "1"); parse_spl_header(SPL_ADDR); }-- 2.13.5
The current code, if there's both an eMMC and an MMC slot available on the board, will swap the MMC indices based on whether we booted from the eMMC or the MMC. This way, the MMC we're supposed to boot on will always have the index 0.
However, this causes various issues, for example when using other components that base their behaviour on the MMC index, such as fastboot.
Let's remove that hack, and take the opposite approach. The MMC will always have the same index, but the bootcmd will pick the same device than the one we booted from. This is done through the introduction of the mmc_bootdev environment variable that will be filled by the board code based on the boot device informations we can get from the SoC.
In order to not introduce regressions, we also need to adjust the fastboot MMC device and the environment device in order to set it to the eMMC, over the MMC, like it used to be the case.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- board/sunxi/board.c | 20 ++++++-------------- include/configs/sunxi-common.h | 36 ++++++++++++++++++++++++++++++------ 2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index e1d48140878f..664c7d2d8126 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -492,20 +492,6 @@ int board_mmc_init(bd_t *bis) return -1; #endif
-#if !defined(CONFIG_SPL_BUILD) && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2 - /* - * On systems with an emmc (mmc2), figure out if we are booting from - * the emmc and if we are make it "mmc dev 0" so that boot.scr, etc. - * are searched there first. Note we only do this for u-boot proper, - * not for the SPL, see spl_boot_device(). - */ - if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_MMC2) { - /* Booting from emmc / mmc2, swap */ - mmc0->block_dev.devnum = 1; - mmc1->block_dev.devnum = 0; - } -#endif - return 0; } #endif @@ -725,12 +711,18 @@ int misc_init_r(void)
setenv("fel_booted", NULL); setenv("fel_scriptaddr", NULL); + setenv("mmc_bootdev", NULL);
boot = spl_boot_device(); /* determine if we are running in FEL mode */ if (boot == BOOT_DEVICE_BOARD) { setenv("fel_booted", "1"); parse_spl_header(SPL_ADDR); + /* or if we booted from MMC, and which one */ + } else if (boot == BOOT_DEVICE_MMC1) { + setenv("mmc_bootdev", "0"); + } else if (boot == BOOT_DEVICE_MMC2) { + setenv("mmc_bootdev", "1"); }
setup_environment(gd->fdt_blob); diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 07c7ffd7f204..79dc3dddd0cc 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -148,7 +148,13 @@ #endif
#if defined(CONFIG_ENV_IS_IN_MMC) -#define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC controller */ +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 +/* If we have two devices (most likely eMMC + MMC), favour the eMMC */ +#define CONFIG_SYS_MMC_ENV_DEV 1 +#else +/* Otherwise, use the only device we have */ +#define CONFIG_SYS_MMC_ENV_DEV 0 +#endif #define CONFIG_SYS_MMC_MAX_DEVICE 4 #elif defined(CONFIG_ENV_IS_NOWHERE) #define CONFIG_ENV_SIZE (128 << 10) @@ -328,9 +334,15 @@ extern int soft_i2c_gpio_scl; #define CONFIG_FASTBOOT_FLASH
#ifdef CONFIG_MMC +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 +/* If we have two devices (most likely eMMC + MMC), favour the eMMC */ +#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1 +#else +/* Otherwise, use the only device we have */ #define CONFIG_FASTBOOT_FLASH_MMC_DEV 0 #endif #endif +#endif
#ifdef CONFIG_USB_FUNCTION_MASS_STORAGE #endif @@ -405,15 +417,28 @@ extern int soft_i2c_gpio_scl; "ramdisk ram " RAMDISK_ADDR_R " 0x4000000\0"
#ifdef CONFIG_MMC -#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 -#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) func(MMC, mmc, 1) +#define BOOTENV_DEV_MMC_AUTO(devtypeu, devtypel, instance) \ + BOOTENV_DEV_MMC(MMC, mmc, 0) \ + BOOTENV_DEV_MMC(MMC, mmc, 1) \ + "bootcmd_mmc_auto=" \ + "if test ${mmc_bootdev} -eq 1; then " \ + "run bootcmd_mmc1; " \ + "run bootcmd_mmc0; " \ + "elif test ${mmc_bootdev} -eq 0; then " \ + "run bootcmd_mmc0; " \ + "run bootcmd_mmc1; " \ + "fi\0" + +#define BOOTENV_DEV_NAME_MMC_AUTO(devtypeu, devtypel, instance) \ + "mmc_auto " + +#define BOOT_TARGET_DEVICES_MMC(func) func(MMC_AUTO, mmc_auto, na) #else -#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) +#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) #endif #else #define BOOT_TARGET_DEVICES_MMC(func) -#define BOOT_TARGET_DEVICES_MMC_EXTRA(func) #endif
#ifdef CONFIG_AHCI @@ -441,7 +466,6 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES(func) \ func(FEL, fel, na) \ BOOT_TARGET_DEVICES_MMC(func) \ - BOOT_TARGET_DEVICES_MMC_EXTRA(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \
On Wed, Aug 23, 2017 at 7:41 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
The current code, if there's both an eMMC and an MMC slot available on the board, will swap the MMC indices based on whether we booted from the eMMC or the MMC. This way, the MMC we're supposed to boot on will always have the index 0.
However, this causes various issues, for example when using other components that base their behaviour on the MMC index, such as fastboot.
Let's remove that hack, and take the opposite approach. The MMC will always have the same index, but the bootcmd will pick the same device than the one we booted from. This is done through the introduction of the mmc_bootdev environment variable that will be filled by the board code based on the boot device informations we can get from the SoC.
In order to not introduce regressions, we also need to adjust the fastboot MMC device and the environment device in order to set it to the eMMC, over the MMC, like it used to be the case.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
board/sunxi/board.c | 20 ++++++-------------- include/configs/sunxi-common.h | 36 ++++++++++++++++++++++++++++++------ 2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index e1d48140878f..664c7d2d8126 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -492,20 +492,6 @@ int board_mmc_init(bd_t *bis) return -1; #endif
-#if !defined(CONFIG_SPL_BUILD) && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
/** On systems with an emmc (mmc2), figure out if we are booting from* the emmc and if we are make it "mmc dev 0" so that boot.scr, etc.* are searched there first. Note we only do this for u-boot proper,* not for the SPL, see spl_boot_device().*/if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_MMC2) {/* Booting from emmc / mmc2, swap */mmc0->block_dev.devnum = 1;mmc1->block_dev.devnum = 0;}-#endif
return 0;} #endif @@ -725,12 +711,18 @@ int misc_init_r(void)
setenv("fel_booted", NULL); setenv("fel_scriptaddr", NULL);
setenv("mmc_bootdev", NULL);
This doesn't apply on master due to commit 382bee57f19b ("env: Rename setenv() to env_set()").
Works as advertised once fixed and applied.
Tested-by: Chen-Yu Tsai wens@csie.org
participants (3)
-
Chen-Yu Tsai -
Jagan Teki -
Maxime Ripard