All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
@ 2017-02-01 10:39 Jean-Jacques Hiblot
  2017-02-03 16:52 ` Tom Rini
  2017-03-20 11:17 ` [U-Boot] " Tom Rini
  0 siblings, 2 replies; 8+ messages in thread
From: Jean-Jacques Hiblot @ 2017-02-01 10:39 UTC (permalink / raw)
  To: u-boot

To keep a consistent MMC device mapping in SPL and in u-boot, let's
register the MMC controllers the same way in u-boot and in the SPL.
In terms of boot time, it doesn't hurt to register more controllers than
needed because the MMC device is initialized only prior being accessed for
the first time.
Having the same device mapping in SPL and u-boot allows us to use the
environment in SPL whatever the MMC boot device.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

This has been tested on DRA7 platforms, AM437x Starter Kit and Beaglebone Black.
I also checked that building the TI-based platforms was okay using buildman:
tools/buildman/buildman -d -e -l omap am33 davinci


 arch/arm/mach-omap2/am33xx/board.c     |  2 +-
 arch/arm/mach-omap2/boot-common.c      | 15 ---------------
 board/BuR/common/common.c              |  2 +-
 board/amazon/kc1/kc1.c                 |  2 --
 board/compulab/cm_t35/cm_t35.c         |  2 +-
 board/compulab/cm_t3517/cm_t3517.c     |  2 +-
 board/compulab/cm_t54/cm_t54.c         |  2 +-
 board/corscience/tricorder/tricorder.c |  2 +-
 board/gumstix/duovero/duovero.c        |  4 +++-
 board/htkw/mcx/mcx.c                   |  2 +-
 board/isee/igep00x0/igep00x0.c         |  2 +-
 board/lg/sniper/sniper.c               |  2 --
 board/logicpd/am3517evm/am3517evm.c    |  2 +-
 board/logicpd/omap3som/omap3logic.c    |  2 +-
 board/quipos/cairo/cairo.c             |  2 +-
 board/technexion/tao3530/tao3530.c     |  2 +-
 board/technexion/twister/twister.c     |  3 +--
 board/teejet/mt_ventoux/mt_ventoux.c   |  3 +--
 board/ti/am3517crane/am3517crane.c     |  2 +-
 board/ti/am57xx/board.c                |  2 +-
 board/ti/beagle/beagle.c               |  2 +-
 board/ti/dra7xx/evm.c                  |  2 +-
 board/ti/evm/evm.c                     |  2 +-
 board/ti/ks2_evm/board_k2g.c           |  2 +-
 board/ti/omap5_uevm/evm.c              |  2 +-
 board/ti/panda/panda.c                 |  4 +++-
 board/ti/sdp4430/sdp.c                 |  4 +++-
 board/ti/ti814x/evm.c                  |  2 +-
 board/timll/devkit8000/devkit8000.c    |  2 +-
 29 files changed, 32 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c
index fb377ce..8fb090c 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -105,7 +105,7 @@ static const struct gpio_bank gpio_bank_am33xx[] = {
 const struct gpio_bank *const omap_gpio_bank = gpio_bank_am33xx;
 #endif
 
-#if defined(CONFIG_OMAP_HSMMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_OMAP_HSMMC)
 int cpu_mmc_init(bd_t *bis)
 {
 	int ret;
diff --git a/arch/arm/mach-omap2/boot-common.c b/arch/arm/mach-omap2/boot-common.c
index 385310b..b6b8d9f 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -205,21 +205,6 @@ void spl_board_init(void)
 #endif
 }
 
-__weak int board_mmc_init(bd_t *bis)
-{
-	switch (spl_boot_device()) {
-	case BOOT_DEVICE_MMC1:
-		omap_mmc_init(0, 0, 0, -1, -1);
-		break;
-	case BOOT_DEVICE_MMC2:
-	case BOOT_DEVICE_MMC2_2:
-		omap_mmc_init(0, 0, 0, -1, -1);
-		omap_mmc_init(1, 0, 0, -1, -1);
-		break;
-	}
-	return 0;
-}
-
 void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 {
 	typedef void __noreturn (*image_entry_noargs_t)(u32 *);
diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index e947e54..8761504 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -684,7 +684,7 @@ int board_eth_init(bd_t *bis)
 	return rv;
 }
 #endif /* defined(CONFIG_DRIVER_TI_CPSW) && !defined(CONFIG_SPL_BUILD) */
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(1, 0, 0, -1, -1);
diff --git a/board/amazon/kc1/kc1.c b/board/amazon/kc1/kc1.c
index 469a83e..b3fa789 100644
--- a/board/amazon/kc1/kc1.c
+++ b/board/amazon/kc1/kc1.c
@@ -166,12 +166,10 @@ int fb_set_reboot_flag(void)
 	return omap_reboot_mode_store("b");
 }
 
-#ifndef CONFIG_SPL_BUILD
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(1, 0, 0, -1, -1);
 }
-#endif
 
 void board_mmc_power_init(void)
 {
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 484651b..4c3e2b2 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -372,7 +372,7 @@ void set_muxconf_regs(void)
 		cm_t3730_set_muxconf();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 #define SB_T35_WP_GPIO 59
 
 int board_mmc_getcd(struct mmc *mmc)
diff --git a/board/compulab/cm_t3517/cm_t3517.c b/board/compulab/cm_t3517/cm_t3517.c
index 8aae248..d9da6d0 100644
--- a/board/compulab/cm_t3517/cm_t3517.c
+++ b/board/compulab/cm_t3517/cm_t3517.c
@@ -115,7 +115,7 @@ int misc_init_r(void)
 	return 0;
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 #define SB_T35_CD_GPIO 144
 #define SB_T35_WP_GPIO 59
 
diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index b4f5d40..7b58fcd 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -96,7 +96,7 @@ uint mmc_get_env_part(struct mmc *mmc)
 }
 #endif
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 #define SB_T54_CD_GPIO 228
 #define SB_T54_WP_GPIO 229
 
diff --git a/board/corscience/tricorder/tricorder.c b/board/corscience/tricorder/tricorder.c
index 0009452..029f20b 100644
--- a/board/corscience/tricorder/tricorder.c
+++ b/board/corscience/tricorder/tricorder.c
@@ -140,7 +140,7 @@ void set_muxconf_regs(void)
 	MUX_TRICORDER();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !(defined(CONFIG_SPL_BUILD))
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/gumstix/duovero/duovero.c b/board/gumstix/duovero/duovero.c
index 3786842..0c89609 100644
--- a/board/gumstix/duovero/duovero.c
+++ b/board/gumstix/duovero/duovero.c
@@ -110,17 +110,19 @@ void set_muxconf_regs(void)
 		   sizeof(struct pad_conf_entry));
 }
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
 }
 
+#if !defined(CONFIG_SPL_BUILD)
 void board_mmc_power_init(void)
 {
 	twl6030_power_mmc_init(0);
 }
 #endif
+#endif
 
 #if defined(CONFIG_CMD_NET)
 
diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c
index 5ef383d..4bf0979 100644
--- a/board/htkw/mcx/mcx.c
+++ b/board/htkw/mcx/mcx.c
@@ -100,7 +100,7 @@ void set_muxconf_regs(void)
 	MUX_MCX();
 }
 
-#if defined(CONFIG_OMAP_HSMMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_OMAP_HSMMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 669f3dd..d5fd9f2 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -196,7 +196,7 @@ int board_eth_init(bd_t *bis)
 static inline void setup_net_chip(void) {}
 #endif
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/lg/sniper/sniper.c b/board/lg/sniper/sniper.c
index 0662449..3c0a6db 100644
--- a/board/lg/sniper/sniper.c
+++ b/board/lg/sniper/sniper.c
@@ -178,12 +178,10 @@ int fb_set_reboot_flag(void)
 	return omap_reboot_mode_store("b");
 }
 
-#ifndef CONFIG_SPL_BUILD
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(1, 0, 0, -1, -1);
 }
-#endif
 
 void board_mmc_power_init(void)
 {
diff --git a/board/logicpd/am3517evm/am3517evm.c b/board/logicpd/am3517evm/am3517evm.c
index a6aff4e..1aaeb8d 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -152,7 +152,7 @@ void set_muxconf_regs(void)
 	MUX_AM3517EVM();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/logicpd/omap3som/omap3logic.c b/board/logicpd/omap3som/omap3logic.c
index de6a060..94b5ffb 100644
--- a/board/logicpd/omap3som/omap3logic.c
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -244,7 +244,7 @@ int board_late_init(void)
 }
 #endif
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/quipos/cairo/cairo.c b/board/quipos/cairo/cairo.c
index 77e4482..555f5c0 100644
--- a/board/quipos/cairo/cairo.c
+++ b/board/quipos/cairo/cairo.c
@@ -62,7 +62,7 @@ void set_muxconf_regs(void)
 	MUX_CAIRO();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/technexion/tao3530/tao3530.c b/board/technexion/tao3530/tao3530.c
index d51b5d9..cba48d4 100644
--- a/board/technexion/tao3530/tao3530.c
+++ b/board/technexion/tao3530/tao3530.c
@@ -179,7 +179,7 @@ void set_muxconf_regs(void)
 #endif
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/technexion/twister/twister.c b/board/technexion/twister/twister.c
index 4a3d094..8afec21 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -130,8 +130,7 @@ int board_eth_init(bd_t *bis)
 	return 0;
 }
 
-#if defined(CONFIG_OMAP_HSMMC) && \
-	!defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_OMAP_HSMMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/teejet/mt_ventoux/mt_ventoux.c b/board/teejet/mt_ventoux/mt_ventoux.c
index c2de1fe..9307258 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.c
+++ b/board/teejet/mt_ventoux/mt_ventoux.c
@@ -291,8 +291,7 @@ int board_eth_init(bd_t *bis)
 	return 0;
 }
 
-#if defined(CONFIG_OMAP_HSMMC) && \
-	!defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_OMAP_HSMMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/am3517crane/am3517crane.c b/board/ti/am3517crane/am3517crane.c
index 8d1c390..faa95d7 100644
--- a/board/ti/am3517crane/am3517crane.c
+++ b/board/ti/am3517crane/am3517crane.c
@@ -63,7 +63,7 @@ void set_muxconf_regs(void)
 	MUX_AM3517CRANE();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 5f2d4df..8b9aef3 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -557,7 +557,7 @@ err:
 }
 #endif
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index cfdab3e..6ed8ad7 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -523,7 +523,7 @@ void set_muxconf_regs(void)
 	MUX_BEAGLE();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index bd1c809..de6fc19 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -679,7 +679,7 @@ err:
 }
 #endif
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index ff3971d..4f132e5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -259,7 +259,7 @@ int board_eth_init(bd_t *bis)
 }
 #endif /* CONFIG_CMD_NET */
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 40edbaa..372fc35 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -102,7 +102,7 @@ s16 divn_val[16] = {
 	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
 };
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	if (psc_enable_module(KS2_LPSC_MMC)) {
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index b5d5ba9..64d772c 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -211,7 +211,7 @@ void set_muxconf_regs(void)
 		   sizeof(struct pad_conf_entry));
 }
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(0, 0, 0, -1, -1);
diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index 13b5daf..187ff3c 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -287,17 +287,19 @@ void set_muxconf_regs(void)
 			   sizeof(struct pad_conf_entry));
 }
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
 }
 
+#if !defined(CONFIG_SPL_BUILD)
 void board_mmc_power_init(void)
 {
 	twl6030_power_mmc_init(0);
 }
 #endif
+#endif
 
 #ifdef CONFIG_USB_EHCI
 
diff --git a/board/ti/sdp4430/sdp.c b/board/ti/sdp4430/sdp.c
index 6037cdd..0eb60e4 100644
--- a/board/ti/sdp4430/sdp.c
+++ b/board/ti/sdp4430/sdp.c
@@ -73,7 +73,7 @@ void set_muxconf_regs(void)
 				 sizeof(struct pad_conf_entry));
 }
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(0, 0, 0, -1, -1);
@@ -81,12 +81,14 @@ int board_mmc_init(bd_t *bis)
 	return 0;
 }
 
+#if !defined(CONFIG_SPL_BUILD)
 void board_mmc_power_init(void)
 {
 	twl6030_power_mmc_init(0);
 	twl6030_power_mmc_init(1);
 }
 #endif
+#endif
 
 /*
  * get_board_rev() - get board revision
diff --git a/board/ti/ti814x/evm.c b/board/ti/ti814x/evm.c
index e406dab..e85794c 100644
--- a/board/ti/ti814x/evm.c
+++ b/board/ti/ti814x/evm.c
@@ -111,7 +111,7 @@ int board_init(void)
 	return 0;
 }
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	omap_mmc_init(1, 0, 0, -1, -1);
diff --git a/board/timll/devkit8000/devkit8000.c b/board/timll/devkit8000/devkit8000.c
index f785dbe..2c913f2 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -130,7 +130,7 @@ void set_muxconf_regs(void)
 	MUX_DEVKIT8000();
 }
 
-#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
 	return omap_mmc_init(0, 0, 0, -1, -1);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-01 10:39 [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot Jean-Jacques Hiblot
@ 2017-02-03 16:52 ` Tom Rini
  2017-02-06 11:25   ` Jean-Jacques Hiblot
  2017-03-20 11:17 ` [U-Boot] " Tom Rini
  1 sibling, 1 reply; 8+ messages in thread
From: Tom Rini @ 2017-02-03 16:52 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
> To keep a consistent MMC device mapping in SPL and in u-boot, let's
> register the MMC controllers the same way in u-boot and in the SPL.
> In terms of boot time, it doesn't hurt to register more controllers than
> needed because the MMC device is initialized only prior being accessed for
> the first time.
> Having the same device mapping in SPL and u-boot allows us to use the
> environment in SPL whatever the MMC boot device.
> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
> 
> This has been tested on DRA7 platforms, AM437x Starter Kit and Beaglebone Black.
> I also checked that building the TI-based platforms was okay using buildman:
> tools/buildman/buildman -d -e -l omap am33 davinci

Did you test this around falcon mode and bootcount as well?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170203/8cce2dae/attachment.sig>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-03 16:52 ` Tom Rini
@ 2017-02-06 11:25   ` Jean-Jacques Hiblot
  2017-02-06 12:49     ` Tom Rini
  0 siblings, 1 reply; 8+ messages in thread
From: Jean-Jacques Hiblot @ 2017-02-06 11:25 UTC (permalink / raw)
  To: u-boot



On 03/02/2017 17:52, Tom Rini wrote:
> On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
>> To keep a consistent MMC device mapping in SPL and in u-boot, let's
>> register the MMC controllers the same way in u-boot and in the SPL.
>> In terms of boot time, it doesn't hurt to register more controllers than
>> needed because the MMC device is initialized only prior being accessed for
>> the first time.
>> Having the same device mapping in SPL and u-boot allows us to use the
>> environment in SPL whatever the MMC boot device.
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>> ---
>>
>> This has been tested on DRA7 platforms, AM437x Starter Kit and Beaglebone Black.
>> I also checked that building the TI-based platforms was okay using buildman:
>> tools/buildman/buildman -d -e -l omap am33 davinci
> Did you test this around falcon mode and bootcount as well?  Thanks!
I tested the falcon boot on beaglebone, DRA7 and am437x. Note that more 
changes are required to make it work properly: FDT memory nodes fixup + 
support for spl_start_uboot() for the am437x SK. They'll be submitted later.

I didn't check bootcount because I didn't know about it. I don't think 
it could have broken since it's not used in SPL and I checked that the 
env was working in u-boot: I'm setting the variable 'boot_os' from the 
u-boot prompt to activate/deactivate the falcon boot.

>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-06 11:25   ` Jean-Jacques Hiblot
@ 2017-02-06 12:49     ` Tom Rini
  2017-02-06 21:13       ` Jean-Jacques Hiblot
  0 siblings, 1 reply; 8+ messages in thread
From: Tom Rini @ 2017-02-06 12:49 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 06, 2017 at 12:25:19PM +0100, Jean-Jacques Hiblot wrote:
> 
> 
> On 03/02/2017 17:52, Tom Rini wrote:
> >On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
> >>To keep a consistent MMC device mapping in SPL and in u-boot, let's
> >>register the MMC controllers the same way in u-boot and in the SPL.
> >>In terms of boot time, it doesn't hurt to register more controllers than
> >>needed because the MMC device is initialized only prior being accessed for
> >>the first time.
> >>Having the same device mapping in SPL and u-boot allows us to use the
> >>environment in SPL whatever the MMC boot device.
> >>
> >>Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> >>---
> >>
> >>This has been tested on DRA7 platforms, AM437x Starter Kit and Beaglebone Black.
> >>I also checked that building the TI-based platforms was okay using buildman:
> >>tools/buildman/buildman -d -e -l omap am33 davinci
> >Did you test this around falcon mode and bootcount as well?  Thanks!
> I tested the falcon boot on beaglebone, DRA7 and am437x. Note that
> more changes are required to make it work properly: FDT memory nodes
> fixup + support for spl_start_uboot() for the am437x SK. They'll be
> submitted later.

Er, SK being broken is confusing since 'spl export' should prepare the
whole DTB.

> I didn't check bootcount because I didn't know about it. I don't
> think it could have broken since it's not used in SPL and I checked
> that the env was working in u-boot: I'm setting the variable
> 'boot_os' from the u-boot prompt to activate/deactivate the falcon
> boot.

Ah yes, nevermind, that never made it into mainline, nevermind.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170206/68537792/attachment.sig>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-06 12:49     ` Tom Rini
@ 2017-02-06 21:13       ` Jean-Jacques Hiblot
  2017-02-10 17:24         ` Jean-Jacques Hiblot
  0 siblings, 1 reply; 8+ messages in thread
From: Jean-Jacques Hiblot @ 2017-02-06 21:13 UTC (permalink / raw)
  To: u-boot



On 06/02/2017 13:49, Tom Rini wrote:
> On Mon, Feb 06, 2017 at 12:25:19PM +0100, Jean-Jacques Hiblot wrote:
>>
>> On 03/02/2017 17:52, Tom Rini wrote:
>>> On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
>>>> To keep a consistent MMC device mapping in SPL and in u-boot, let's
>>>> register the MMC controllers the same way in u-boot and in the SPL.
>>>> In terms of boot time, it doesn't hurt to register more controllers than
>>>> needed because the MMC device is initialized only prior being accessed for
>>>> the first time.
>>>> Having the same device mapping in SPL and u-boot allows us to use the
>>>> environment in SPL whatever the MMC boot device.
>>>>
>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>>> ---
>>>>
>>>> This has been tested on DRA7 platforms, AM437x Starter Kit and Beaglebone Black.
>>>> I also checked that building the TI-based platforms was okay using buildman:
>>>> tools/buildman/buildman -d -e -l omap am33 davinci
>>> Did you test this around falcon mode and bootcount as well?  Thanks!
>> I tested the falcon boot on beaglebone, DRA7 and am437x. Note that
>> more changes are required to make it work properly: FDT memory nodes
>> fixup + support for spl_start_uboot() for the am437x SK. They'll be
>> submitted later.
> Er, SK being broken is confusing since 'spl export' should prepare the
> whole DTB.
I didn't write the FDT memory fixup patch so I'm not 100% confident in 
what my following comment:  This patch adjusts dynamically the memory 
nodes in the DTB. I guess that's required because the amount of memory 
is read from an on-board EEPROM.
>
>> I didn't check bootcount because I didn't know about it. I don't
>> think it could have broken since it's not used in SPL and I checked
>> that the env was working in u-boot: I'm setting the variable
>> 'boot_os' from the u-boot prompt to activate/deactivate the falcon
>> boot.
> Ah yes, nevermind, that never made it into mainline, nevermind.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-06 21:13       ` Jean-Jacques Hiblot
@ 2017-02-10 17:24         ` Jean-Jacques Hiblot
  2017-02-10 21:48           ` Tom Rini
  0 siblings, 1 reply; 8+ messages in thread
From: Jean-Jacques Hiblot @ 2017-02-10 17:24 UTC (permalink / raw)
  To: u-boot



On 06/02/2017 22:13, Jean-Jacques Hiblot wrote:
>
>
> On 06/02/2017 13:49, Tom Rini wrote:
>> On Mon, Feb 06, 2017 at 12:25:19PM +0100, Jean-Jacques Hiblot wrote:
>>>
>>> On 03/02/2017 17:52, Tom Rini wrote:
>>>> On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
>>>>> To keep a consistent MMC device mapping in SPL and in u-boot, let's
>>>>> register the MMC controllers the same way in u-boot and in the SPL.
>>>>> In terms of boot time, it doesn't hurt to register more 
>>>>> controllers than
>>>>> needed because the MMC device is initialized only prior being 
>>>>> accessed for
>>>>> the first time.
>>>>> Having the same device mapping in SPL and u-boot allows us to use the
>>>>> environment in SPL whatever the MMC boot device.
>>>>>
>>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>>>> ---
>>>>>
>>>>> This has been tested on DRA7 platforms, AM437x Starter Kit and 
>>>>> Beaglebone Black.
>>>>> I also checked that building the TI-based platforms was okay using 
>>>>> buildman:
>>>>> tools/buildman/buildman -d -e -l omap am33 davinci
>>>> Did you test this around falcon mode and bootcount as well? Thanks!
>>> I tested the falcon boot on beaglebone, DRA7 and am437x. Note that
>>> more changes are required to make it work properly: FDT memory nodes
>>> fixup + support for spl_start_uboot() for the am437x SK. They'll be
>>> submitted later.
>> Er, SK being broken is confusing since 'spl export' should prepare the
>> whole DTB.
> I didn't write the FDT memory fixup patch so I'm not 100% confident in 
> what my following comment:  This patch adjusts dynamically the memory 
> nodes in the DTB. I guess that's required because the amount of memory 
> is read from an on-board EEPROM.

After a bit of research here is the explanation, the patch adds a call 
to arch_fixup_fdt() so that the memory banks are properly described in 
the dtb.
This is required in our case because of the way the dtb is programmed in 
the flash/mmc: we don't use "spl export", instead we write the dtb as-is 
(though we do customize it on dev station with fdtput).


JJ

>>
>>> I didn't check bootcount because I didn't know about it. I don't
>>> think it could have broken since it's not used in SPL and I checked
>>> that the env was working in u-boot: I'm setting the variable
>>> 'boot_os' from the u-boot prompt to activate/deactivate the falcon
>>> boot.
>> Ah yes, nevermind, that never made it into mainline, nevermind.
>>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-10 17:24         ` Jean-Jacques Hiblot
@ 2017-02-10 21:48           ` Tom Rini
  0 siblings, 0 replies; 8+ messages in thread
From: Tom Rini @ 2017-02-10 21:48 UTC (permalink / raw)
  To: u-boot

On Fri, Feb 10, 2017 at 06:24:18PM +0100, Jean-Jacques Hiblot wrote:
> 
> 
> On 06/02/2017 22:13, Jean-Jacques Hiblot wrote:
> >
> >
> >On 06/02/2017 13:49, Tom Rini wrote:
> >>On Mon, Feb 06, 2017 at 12:25:19PM +0100, Jean-Jacques Hiblot wrote:
> >>>
> >>>On 03/02/2017 17:52, Tom Rini wrote:
> >>>>On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:
> >>>>>To keep a consistent MMC device mapping in SPL and in u-boot, let's
> >>>>>register the MMC controllers the same way in u-boot and in the SPL.
> >>>>>In terms of boot time, it doesn't hurt to register more
> >>>>>controllers than
> >>>>>needed because the MMC device is initialized only prior
> >>>>>being accessed for
> >>>>>the first time.
> >>>>>Having the same device mapping in SPL and u-boot allows us to use the
> >>>>>environment in SPL whatever the MMC boot device.
> >>>>>
> >>>>>Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> >>>>>---
> >>>>>
> >>>>>This has been tested on DRA7 platforms, AM437x Starter Kit
> >>>>>and Beaglebone Black.
> >>>>>I also checked that building the TI-based platforms was
> >>>>>okay using buildman:
> >>>>>tools/buildman/buildman -d -e -l omap am33 davinci
> >>>>Did you test this around falcon mode and bootcount as well? Thanks!
> >>>I tested the falcon boot on beaglebone, DRA7 and am437x. Note that
> >>>more changes are required to make it work properly: FDT memory nodes
> >>>fixup + support for spl_start_uboot() for the am437x SK. They'll be
> >>>submitted later.
> >>Er, SK being broken is confusing since 'spl export' should prepare the
> >>whole DTB.
> >I didn't write the FDT memory fixup patch so I'm not 100%
> >confident in what my following comment:  This patch adjusts
> >dynamically the memory nodes in the DTB. I guess that's required
> >because the amount of memory is read from an on-board EEPROM.
> 
> After a bit of research here is the explanation, the patch adds a
> call to arch_fixup_fdt() so that the memory banks are properly
> described in the dtb.
> This is required in our case because of the way the dtb is
> programmed in the flash/mmc: we don't use "spl export", instead we
> write the dtb as-is (though we do customize it on dev station with
> fdtput).

So, yes.  If you don't use the built-in mechanism to prepare a DTB for
use with falcon you do have to set all of the values required via
fdtput/similar (I've suggested as much for customers wanting to
productize falcon mode, "spl export" doesn't fit as well into upgrade
paths when run via Linux for example).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170210/8f601746/attachment.sig>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot
  2017-02-01 10:39 [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot Jean-Jacques Hiblot
  2017-02-03 16:52 ` Tom Rini
@ 2017-03-20 11:17 ` Tom Rini
  1 sibling, 0 replies; 8+ messages in thread
From: Tom Rini @ 2017-03-20 11:17 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 01, 2017 at 11:39:14AM +0100, Jean-Jacques Hiblot wrote:

> To keep a consistent MMC device mapping in SPL and in u-boot, let's
> register the MMC controllers the same way in u-boot and in the SPL.
> In terms of boot time, it doesn't hurt to register more controllers than
> needed because the MMC device is initialized only prior being accessed for
> the first time.
> Having the same device mapping in SPL and u-boot allows us to use the
> environment in SPL whatever the MMC boot device.
> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170320/945207a9/attachment.sig>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-03-20 11:17 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-01 10:39 [U-Boot] [PATCH] ti: boot: Register the MMC controllers in SPL in the same way as in u-boot Jean-Jacques Hiblot
2017-02-03 16:52 ` Tom Rini
2017-02-06 11:25   ` Jean-Jacques Hiblot
2017-02-06 12:49     ` Tom Rini
2017-02-06 21:13       ` Jean-Jacques Hiblot
2017-02-10 17:24         ` Jean-Jacques Hiblot
2017-02-10 21:48           ` Tom Rini
2017-03-20 11:17 ` [U-Boot] " Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.