[U-Boot] [PATCH 0/6] sunxi: Add second sdcard slot support, including eMMC boot

[U-Boot] [PATCH 0/6] sunxi: Add second sdcard slot support, including eMMC boot

[Hans de Goede]

Hi Ian, et al,

Here is a patch-set adding support for the second sdcard slot found on some
sunxi devices. This includes support for eMMC-s connected to sdc2 (so that
they are bootable), as found on e.g. the Mele-M3.

For the eMMC case this set also adds support to detect what device we're
actually booting from, so that a single u-boot binary can be used to boot
from boot the external slot and the eMMC. With this in place you can boot
an image from the external sd, and if it works, dd it to the eMMC, and boot
from the eMMC, simple as that.

Please review, and let me know if you want me to add it to -next with your
acks, or if you're going to push it to -next yourself.

Thanks & Regards,

Hans

[U-Boot] [PATCH 1/6] sunxi: Add sunxi_gpio_get_val function

[Hans de Goede]

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/cpu/armv7/sunxi/pinmux.c      | 13 +++++++++++++
 arch/arm/include/asm/arch-sunxi/gpio.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/pinmux.c b/arch/arm/cpu/armv7/sunxi/pinmux.c
index 1f2843f..a3e5bfc 100644
--- a/arch/arm/cpu/armv7/sunxi/pinmux.c
+++ b/arch/arm/cpu/armv7/sunxi/pinmux.c
@@ -59,3 +59,16 @@ int sunxi_gpio_set_pull(u32 pin, u32 val)
 
 	return 0;
 }
+
+int sunxi_gpio_get_val(u32 pin)
+{
+	u32 dat;
+	u32 bank = GPIO_BANK(pin);
+	u32 offset = GPIO_NUM(pin);
+	struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
+
+	dat = readl(&pio->dat);
+	dat >>= offset;
+
+	return dat & 0x1;
+}
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h
index f7f3d8c..c049d39 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -143,6 +143,7 @@ int sunxi_gpio_set_cfgpin(u32 pin, u32 val);
 int sunxi_gpio_get_cfgpin(u32 pin);
 int sunxi_gpio_set_drv(u32 pin, u32 val);
 int sunxi_gpio_set_pull(u32 pin, u32 val);
+int sunxi_gpio_get_val(u32 pin);
 int sunxi_name_to_gpio(const char *name);
 #define name_to_gpio(name) sunxi_name_to_gpio(name)
 
-- 
2.1.0

[U-Boot] [PATCH 1/6] sunxi: Add sunxi_gpio_get_val function

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

drivers/gpio/sunxi_gpio.c already has sunxi_gpio_input exported via the
standard gpio_get_value name.

Ian.

[U-Boot] [PATCH 1/6] sunxi: Add sunxi_gpio_get_val function

[Hans de Goede]

Hi Ian,

Thanks for the reviews!

On 10/04/2014 10:14 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> drivers/gpio/sunxi_gpio.c already has sunxi_gpio_input exported via the
> standard gpio_get_value name.

Oops, I actually already checked if we did not have such a function, as I
thought that we should have one, but I could not find it.

Ah well.

I'll drop this from the v2 of the series.

Regards,

Hans

[U-Boot] [PATCH 2/6] sunxi: Add mmc card-detect functionality

[Hans de Goede]

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 board/sunxi/Kconfig     | 27 +++++++++++++++++++++++++++
 drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++
 2 files changed, 47 insertions(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 622f7b4..72d6dfa 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -32,4 +32,31 @@ config USB_KEYBOARD
 	Say Y here to add support for using a USB keyboard (typically used
 	in combination with a graphical console on HDMI).
 
+config MMC0_CD_PIN
+	int "Card detect pin for mmc0"
+	default -1
+	---help---
+	Set the card detect pin for mmc0, set to -1 to not use cd. The pins
+	are numbered as follows PA0 - PA17 are pin number 0 - 17, PB0 - PB23
+	are 32 - 55, PC0 - PC24 are 64 - 88, etc. Most boards use PH1 for
+	mmc0 cd, which is pin nr 225.
+
+config MMC1_CD_PIN
+	int "Card detect pin for mmc1"
+	default -1
+	---help---
+	See MMC0_CD_PIN help text.
+
+config MMC2_CD_PIN
+	int "Card detect pin for mmc2"
+	default -1
+	---help---
+	See MMC0_CD_PIN help text.
+
+config MMC3_CD_PIN
+	int "Card detect pin for mmc3"
+	default -1
+	---help---
+	See MMC0_CD_PIN help text.
+
 endif
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index bc2c4b3..a397b86 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -14,6 +14,7 @@
 #include <asm/io.h>
 #include <asm/arch/clock.h>
 #include <asm/arch/cpu.h>
+#include <asm/arch/gpio.h>
 #include <asm/arch/mmc.h>
 
 struct sunxi_mmc_host {
@@ -343,10 +344,29 @@ out:
 	return error;
 }
 
+static int sunxi_mmc_getcd(struct mmc *mmc)
+{
+	struct sunxi_mmc_host *mmchost = mmc->priv;
+	int cd_pin = -1;
+
+	switch (mmchost->mmc_no) {
+	case 0: cd_pin = CONFIG_MMC0_CD_PIN; break;
+	case 1: cd_pin = CONFIG_MMC1_CD_PIN; break;
+	case 2: cd_pin = CONFIG_MMC2_CD_PIN; break;
+	case 3: cd_pin = CONFIG_MMC3_CD_PIN; break;
+	}
+
+	if (cd_pin == -1)
+		return 1;
+
+	return !sunxi_gpio_get_val(cd_pin);
+}
+
 static const struct mmc_ops sunxi_mmc_ops = {
 	.send_cmd	= mmc_send_cmd,
 	.set_ios	= mmc_set_ios,
 	.init		= mmc_core_init,
+	.getcd		= sunxi_mmc_getcd,
 };
 
 int sunxi_mmc_init(int sdc_no)
-- 
2.1.0

[U-Boot] [PATCH 2/6] sunxi: Add mmc card-detect functionality

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  board/sunxi/Kconfig     | 27 +++++++++++++++++++++++++++
>  drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 622f7b4..72d6dfa 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -32,4 +32,31 @@ config USB_KEYBOARD
>  	Say Y here to add support for using a USB keyboard (typically used
>  	in combination with a graphical console on HDMI).
>  
> +config MMC0_CD_PIN
> +	int "Card detect pin for mmc0"
> +	default -1
> +	---help---
> +	Set the card detect pin for mmc0, set to -1 to not use cd. The pins
> +	are numbered as follows PA0 - PA17 are pin number 0 - 17, PB0 - PB23
> +	are 32 - 55, PC0 - PC24 are 64 - 88, etc. Most boards use PH1 for
> +	mmc0 cd, which is pin nr 225.

Is there any way we could use the same trick as for SATAPWR and allow
this to be specified as something like GPx(y) instead of requiring this
complex mapping in the help text? Might be possible with some
combination of Kconfig and cpp trickery?

Maybe the simplest solution is to make this a string and pass it to
name_to_gpio at runtime (e.g gpio = name_to_gpio(CONFIG_MMC0_CD_PIN)),
although that has the disadvantage of being runtime only check.

Ian.

[U-Boot] [PATCH 2/6] sunxi: Add mmc card-detect functionality

[Hans de Goede]

Hi,

On 10/04/2014 10:30 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>  board/sunxi/Kconfig     | 27 +++++++++++++++++++++++++++
>>  drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++
>>  2 files changed, 47 insertions(+)
>>
>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>> index 622f7b4..72d6dfa 100644
>> --- a/board/sunxi/Kconfig
>> +++ b/board/sunxi/Kconfig
>> @@ -32,4 +32,31 @@ config USB_KEYBOARD
>>  	Say Y here to add support for using a USB keyboard (typically used
>>  	in combination with a graphical console on HDMI).
>>  
>> +config MMC0_CD_PIN
>> +	int "Card detect pin for mmc0"
>> +	default -1
>> +	---help---
>> +	Set the card detect pin for mmc0, set to -1 to not use cd. The pins
>> +	are numbered as follows PA0 - PA17 are pin number 0 - 17, PB0 - PB23
>> +	are 32 - 55, PC0 - PC24 are 64 - 88, etc. Most boards use PH1 for
>> +	mmc0 cd, which is pin nr 225.
> 
> Is there any way we could use the same trick as for SATAPWR and allow
> this to be specified as something like GPx(y) instead of requiring this
> complex mapping in the help text? Might be possible with some
> combination of Kconfig and cpp trickery?
> 
> Maybe the simplest solution is to make this a string and pass it to
> name_to_gpio at runtime (e.g gpio = name_to_gpio(CONFIG_MMC0_CD_PIN)),
> although that has the disadvantage of being runtime only check.

I agree that being able to use symbolic names is much better, but I
could not find a Kconfig / cpp trickery way to do this. I think that
using name_to_gpio is a good solution for this, so that is what I'll
do for v2.

Regards,

Hans

[U-Boot] [PATCH 3/6] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option

[Hans de Goede]

Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
check is not necessary with Kconfig, because only options explicitly marked
as also being for the SPL get set during SPL builds.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 board/sunxi/Kconfig | 8 ++++++++
 board/sunxi/board.c | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 72d6dfa..c9b459a 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -32,6 +32,14 @@ config USB_KEYBOARD
 	Say Y here to add support for using a USB keyboard (typically used
 	in combination with a graphical console on HDMI).
 
+config MMC_SUNXI_SLOT_EXTRA
+	int "mmc extra slot number"
+	default -1
+	---help---
+	sunxi builds always enable mmc0, some boards also have a sdcard slot
+	or emmc on mmc2 or mmc3. Setting this to 2 or 3 will enable support
+	for this.
+
 config MMC0_CD_PIN
 	int "Card detect pin for mmc0"
 	default -1
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e819b12..4d602ca 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
 {
 	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
 	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
-#if !defined (CONFIG_SPL_BUILD) && defined (CONFIG_MMC_SUNXI_SLOT_EXTRA)
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
 	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
 	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
 #endif
-- 
2.1.0

[U-Boot] [PATCH 3/6] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
> check is not necessary with Kconfig, because only options explicitly marked
> as also being for the SPL get set during SPL builds.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

If we come across a system with e.g. 3 slots then this is just going to
get more complex, isn't it? Shall we bite the bullet now and got
straight to a bool option per potential slot?

> ---
>  board/sunxi/Kconfig | 8 ++++++++
>  board/sunxi/board.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 72d6dfa..c9b459a 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -32,6 +32,14 @@ config USB_KEYBOARD
>  	Say Y here to add support for using a USB keyboard (typically used
>  	in combination with a graphical console on HDMI).
>  
> +config MMC_SUNXI_SLOT_EXTRA
> +	int "mmc extra slot number"
> +	default -1
> +	---help---
> +	sunxi builds always enable mmc0, some boards also have a sdcard slot
> +	or emmc on mmc2 or mmc3. Setting this to 2 or 3 will enable support
> +	for this.
> +
>  config MMC0_CD_PIN
>  	int "Card detect pin for mmc0"
>  	default -1
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index e819b12..4d602ca 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
>  {
>  	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
>  	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
> -#if !defined (CONFIG_SPL_BUILD) && defined (CONFIG_MMC_SUNXI_SLOT_EXTRA)
> +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
>  	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
>  	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
>  #endif

[U-Boot] [PATCH 3/6] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option

[Hans de Goede]

Hi,

On 10/04/2014 10:32 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
>> check is not necessary with Kconfig, because only options explicitly marked
>> as also being for the SPL get set during SPL builds.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> If we come across a system with e.g. 3 slots then this is just going to
> get more complex, isn't it? Shall we bite the bullet now and got
> straight to a bool option per potential slot?

I think that the current solution is somewhat more KISS then doing a bool
per slot. So lets wait with moving to a bool per mmc controller, until such
a hypothetical board with 3 mmc slots actually shows up, and keep what we've
for now.

Regards,

Hans


> 
>> ---
>>  board/sunxi/Kconfig | 8 ++++++++
>>  board/sunxi/board.c | 2 +-
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>> index 72d6dfa..c9b459a 100644
>> --- a/board/sunxi/Kconfig
>> +++ b/board/sunxi/Kconfig
>> @@ -32,6 +32,14 @@ config USB_KEYBOARD
>>  	Say Y here to add support for using a USB keyboard (typically used
>>  	in combination with a graphical console on HDMI).
>>  
>> +config MMC_SUNXI_SLOT_EXTRA
>> +	int "mmc extra slot number"
>> +	default -1
>> +	---help---
>> +	sunxi builds always enable mmc0, some boards also have a sdcard slot
>> +	or emmc on mmc2 or mmc3. Setting this to 2 or 3 will enable support
>> +	for this.
>> +
>>  config MMC0_CD_PIN
>>  	int "Card detect pin for mmc0"
>>  	default -1
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index e819b12..4d602ca 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -110,7 +110,7 @@ int board_mmc_init(bd_t *bis)
>>  {
>>  	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
>>  	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
>> -#if !defined (CONFIG_SPL_BUILD) && defined (CONFIG_MMC_SUNXI_SLOT_EXTRA)
>> +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
>>  	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
>>  	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
>>  #endif
> 
> 

[U-Boot] [PATCH 3/6] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option

[Ian Campbell]

On Sun, 2014-10-05 at 17:00 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/04/2014 10:32 AM, Ian Campbell wrote:
> > On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> >> Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
> >> check is not necessary with Kconfig, because only options explicitly marked
> >> as also being for the SPL get set during SPL builds.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > If we come across a system with e.g. 3 slots then this is just going to
> > get more complex, isn't it? Shall we bite the bullet now and got
> > straight to a bool option per potential slot?
> 
> I think that the current solution is somewhat more KISS then doing a bool
> per slot. So lets wait with moving to a bool per mmc controller, until such
> a hypothetical board with 3 mmc slots actually shows up, and keep what we've
> for now.

That's OK so long as we don't try to care about "forwards compatibility"
for .config files. I have a feeling that we don't in general, I expect
very few people are using oldconfig as opposed to rerunning defconfig,
since there is very little opportunity to tweak things once you have the
defconfig for a board.

Ian.

[U-Boot] [PATCH 4/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting

[Hans de Goede]

sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
booting, and make that one "mmc dev 0" so that a single u-boot binary can
be used for both the onboard eMMC and for external sdcards.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/include/asm/arch-sunxi/mmc.h |  2 +-
 board/sunxi/board.c                   | 25 +++++++++++++++++++++++--
 drivers/mmc/sunxi_mmc.c               |  7 ++-----
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h b/arch/arm/include/asm/arch-sunxi/mmc.h
index 53196e3..ff2602d 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -120,5 +120,5 @@ struct sunxi_mmc {
 #define SUNXI_MMC_IDIE_TXIRQ		(0x1 << 0)
 #define SUNXI_MMC_IDIE_RXIRQ		(0x1 << 1)
 
-int sunxi_mmc_init(int sdc_no);
+struct mmc *sunxi_mmc_init(int sdc_no);
 #endif /* _SUNXI_MMC_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4d602ca..0a7be31 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -12,6 +12,7 @@
  */
 
 #include <common.h>
+#include <mmc.h>
 #ifdef CONFIG_AXP152_POWER
 #include <axp152.h>
 #endif
@@ -108,11 +109,31 @@ static void mmc_pinmux_setup(int sdc)
 
 int board_mmc_init(bd_t *bis)
 {
+	__maybe_unused struct mmc *mmc0, *mmc1;
+	__maybe_unused char buf[512];
+
 	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
-	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+	mmc0 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
 #if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
 	mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
-	sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+	mmc1 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+#endif
+
+#if CONFIG_MMC_SUNXI_SLOT == 0 && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
+	/*
+	 * Both mmc0 and mmc2 are bootable, figure out where we're booting
+	 * from. Try mmc0 first, just like the brom does.
+	 */
+	if (mmc_getcd(mmc0) && mmc_init(mmc0) == 0 &&
+	    mmc0->block_dev.block_read(0, 16, 1, buf) == 1) {
+		buf[12] = 0;
+		if (strcmp(&buf[4], "eGON.BT0") == 0)
+			return 0;
+	}
+
+	/* no bootable card in mmc0, so we must be booting from mmc2, swap */
+	mmc0->block_dev.dev = 1;
+	mmc1->block_dev.dev = 0;
 #endif
 
 	return 0;
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index a397b86..2077c0a 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -369,7 +369,7 @@ static const struct mmc_ops sunxi_mmc_ops = {
 	.getcd		= sunxi_mmc_getcd,
 };
 
-int sunxi_mmc_init(int sdc_no)
+struct mmc *sunxi_mmc_init(int sdc_no)
 {
 	struct mmc_config *cfg = &mmc_host[sdc_no].cfg;
 
@@ -392,8 +392,5 @@ int sunxi_mmc_init(int sdc_no)
 	mmc_resource_init(sdc_no);
 	mmc_clk_io_on(sdc_no);
 
-	if (mmc_create(cfg, &mmc_host[sdc_no]) == NULL)
-		return -1;
-
-	return 0;
+	return mmc_create(cfg, &mmc_host[sdc_no]);
 }
-- 
2.1.0

[U-Boot] [PATCH 4/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
> booting, and make that one "mmc dev 0" so that a single u-boot binary can
> be used for both the onboard eMMC and for external sdcards.

Where does the dependency on dev 0 being the boot device come from? Is
it just the env via CONFIG_SYS_MMC_ENV_DEV?

If it's just that then is it allowable to define CONFIG_SYS_MMC_ENV_DEV
as a call to a function which returns the appropriate number?

Or maybe mmc->block_dev.dev already doesn't correspond to the h/w
controller number? So dev==0 is completely arbitrary?

> +#if CONFIG_MMC_SUNXI_SLOT == 0 && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
> +	/*
> +	 * Both mmc0 and mmc2 are bootable, figure out where we're booting
> +	 * from. Try mmc0 first, just like the brom does.
> +	 */
> +	if (mmc_getcd(mmc0) && mmc_init(mmc0) == 0 &&
> +	    mmc0->block_dev.block_read(0, 16, 1, buf) == 1) {
> +		buf[12] = 0;
> +		if (strcmp(&buf[4], "eGON.BT0") == 0)
> +			return 0;

This just checks if the mmc is bootable, not necessarily that we booted
from it, does it? Or is "just like the brom does" implying that the
bootrom would always have booted mmc0 if this signature was there? is
that check sufficient or does the brom check other stuff, e.g.
signatures etc or have a fallback path if mmc0 fails to boot somehow?

Ian.

[U-Boot] [PATCH 4/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting

[Hans de Goede]

On 10/04/2014 10:35 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
>> booting, and make that one "mmc dev 0" so that a single u-boot binary can
>> be used for both the onboard eMMC and for external sdcards.
> 
> Where does the dependency on dev 0 being the boot device come from? Is
> it just the env via CONFIG_SYS_MMC_ENV_DEV?

No, the main reason why we need dev 0 to be the mmc we're actually booting
from is because that is where the SPL will load the tertiary payload
(the actual u-boot binary in our case) from, see:

common/spl/spl_mmc.c

Which has dev 0 hardcoded everywhere.

> If it's just that then is it allowable to define CONFIG_SYS_MMC_ENV_DEV
> as a call to a function which returns the appropriate number?
> 
> Or maybe mmc->block_dev.dev already doesn't correspond to the h/w
> controller number? So dev==0 is completely arbitrary?

Right, if we add mmc3 and then mmc0 for example, then the block_dev.dev field
will be 0 for mmc3 and 1 for mmc1, the dev field is just an incrementing
integer giving each controller added a unique id as it gets added.

>> +#if CONFIG_MMC_SUNXI_SLOT == 0 && CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
>> +	/*
>> +	 * Both mmc0 and mmc2 are bootable, figure out where we're booting
>> +	 * from. Try mmc0 first, just like the brom does.
>> +	 */
>> +	if (mmc_getcd(mmc0) && mmc_init(mmc0) == 0 &&
>> +	    mmc0->block_dev.block_read(0, 16, 1, buf) == 1) {
>> +		buf[12] = 0;
>> +		if (strcmp(&buf[4], "eGON.BT0") == 0)
>> +			return 0;
> 
> This just checks if the mmc is bootable, not necessarily that we booted
> from it, does it?

Correct, unfortunately the brom is very good in cleaning up after itself,
once we enter the SPL the mux for all involved pins have been reset to
0 (gpio input), all the involved clocks have been disabled, and all the
mmc controllers have been reset, so there is no way to really tell where
we're bootint from.

> Or is "just like the brom does" implying that the
> bootrom would always have booted mmc0 if this signature was there?

Yes.

> is that check sufficient or does the brom check other stuff, e.g.
> signatures etc.

AFAIK that check is all it does.

> or have a fallback path if mmc0 fails to boot somehow?

There is no fallback path, if you insert a sdcard with a bad
u-boot build, things will just hang, the brom is not smart enough
to switch over to an internal boot medium in this case. So I believe
that the check which I'm adding should be sufficient to determine whether
or not we're booting from mmc0. I really don't expect people to leave
a bootable sdcard in slot0, they could have a sdcard there to store data,
but in that case I would expect it to not have the magic boot signature.

Regards,

Hans

[U-Boot] [PATCH 4/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting

[Ian Campbell]

On Sun, 2014-10-05 at 17:10 +0200, Hans de Goede wrote:
> 
> On 10/04/2014 10:35 AM, Ian Campbell wrote:
> > On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> >> sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
> >> booting, and make that one "mmc dev 0" so that a single u-boot binary can
> >> be used for both the onboard eMMC and for external sdcards.
> > 
> > Where does the dependency on dev 0 being the boot device come from? Is
> > it just the env via CONFIG_SYS_MMC_ENV_DEV?
> 
> No, the main reason why we need dev 0 to be the mmc we're actually booting
> from is because that is where the SPL will load the tertiary payload
> (the actual u-boot binary in our case) from, see:
> 
> common/spl/spl_mmc.c
> 
> Which has dev 0 hardcoded everywhere.

I see. Could you paste this bit of reasoning into the commit log please?
(pretty much s/No, t/T/ on the above would do IMHO)

> There is no fallback path, if you insert a sdcard with a bad
> u-boot build, things will just hang, the brom is not smart enough
> to switch over to an internal boot medium in this case. So I believe
> that the check which I'm adding should be sufficient to determine whether
> or not we're booting from mmc0. I really don't expect people to leave
> a bootable sdcard in slot0, they could have a sdcard there to store data,
> but in that case I would expect it to not have the magic boot signature.

This makes sense too, thanks.

Ian

[U-Boot] [PATCH 4/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting

[Hans de Goede]

Hi,

On 10/06/2014 10:33 AM, Ian Campbell wrote:
> On Sun, 2014-10-05 at 17:10 +0200, Hans de Goede wrote:
>>
>> On 10/04/2014 10:35 AM, Ian Campbell wrote:
>>> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>>>> sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
>>>> booting, and make that one "mmc dev 0" so that a single u-boot binary can
>>>> be used for both the onboard eMMC and for external sdcards.
>>>
>>> Where does the dependency on dev 0 being the boot device come from? Is
>>> it just the env via CONFIG_SYS_MMC_ENV_DEV?
>>
>> No, the main reason why we need dev 0 to be the mmc we're actually booting
>> from is because that is where the SPL will load the tertiary payload
>> (the actual u-boot binary in our case) from, see:
>>
>> common/spl/spl_mmc.c
>>
>> Which has dev 0 hardcoded everywhere.
> 
> I see. Could you paste this bit of reasoning into the commit log please?
> (pretty much s/No, t/T/ on the above would do IMHO)

Done for v2.

Regards,

Hans

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Hans de Goede]

None of the known sunxi devices actually use mmc1 routed through PH, where
as some devices do actually use mmc1 routed through PG, so change the routing
of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
PH, we will need to change things to be a bit more flexible.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
 board/sunxi/board.c                    | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h
index c049d39..1fb3e0a 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -117,6 +117,8 @@ enum sunxi_gpio_number {
 #define SUN5I_GPB19_UART0_TX	2
 #define SUN5I_GPB20_UART0_RX	2
 
+#define SUN5I_GPG3_SDC1		2
+
 #define SUN5I_GPG3_UART1_TX	4
 #define SUN5I_GPG4_UART1_RX	4
 
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 0a7be31..23f8887 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -75,9 +75,9 @@ static void mmc_pinmux_setup(int sdc)
 		break;
 
 	case 1:
-		/* CMD-PH22, CLK-PH23, D0~D3-PH24~27 : 5 */
-		for (pin = SUNXI_GPH(22); pin <= SUNXI_GPH(27); pin++) {
-			sunxi_gpio_set_cfgpin(pin, SUN4I_GPH22_SDC1);
+		/* CMD-PG3, CLK-PG4, D0~D3-PG5-8 */
+		for (pin = SUNXI_GPG(3); pin <= SUNXI_GPG(8); pin++) {
+			sunxi_gpio_set_cfgpin(pin, SUN5I_GPG3_SDC1);
 			sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
 			sunxi_gpio_set_drv(pin, 2);
 		}
-- 
2.1.0

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> None of the known sunxi devices actually use mmc1 routed through PH, where
> as some devices do actually use mmc1 routed through PG, so change the routing
> of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
> PH, we will need to change things to be a bit more flexible.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although it seems that adding a Kconfig choice option would only be a
dozen or so lines of pretty trivial stuff if we wanted to do it now.

Ian.

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Hans de Goede]

Hi,

On 10/04/2014 10:37 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> None of the known sunxi devices actually use mmc1 routed through PH, where
>> as some devices do actually use mmc1 routed through PG, so change the routing
>> of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
>> PH, we will need to change things to be a bit more flexible.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Although it seems that adding a Kconfig choice option would only be a
> dozen or so lines of pretty trivial stuff if we wanted to do it now.

This mostly seems to be a sun4i/sun7i vs sun5i thing. mmc1 could be routed
through PH on sun4i/sun7i, but actually is never used there, as PH typically
is used for gpio purposed on sun4i/sun7i, where as on sun5i (which has way
less pins), mmc1 goes out on PG, and actually is used as such there.

I have considered keeping the old pinmux settings using #if defined SUN5I
for the new ones, but since the old ones are never used just replacing
them seems better.

Regards,

Hans

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Ian Campbell]

On Mon, 2014-10-06 at 10:37 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/04/2014 10:37 AM, Ian Campbell wrote:
> > On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> >> None of the known sunxi devices actually use mmc1 routed through PH, where
> >> as some devices do actually use mmc1 routed through PG, so change the routing
> >> of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
> >> PH, we will need to change things to be a bit more flexible.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Although it seems that adding a Kconfig choice option would only be a
> > dozen or so lines of pretty trivial stuff if we wanted to do it now.
> 
> This mostly seems to be a sun4i/sun7i vs sun5i thing. mmc1 could be routed
> through PH on sun4i/sun7i, but actually is never used there, as PH typically
> is used for gpio purposed on sun4i/sun7i, where as on sun5i (which has way
> less pins), mmc1 goes out on PG, and actually is used as such there.
> 
> I have considered keeping the old pinmux settings using #if defined SUN5I
> for the new ones, but since the old ones are never used just replacing
> them seems better.

Sure.

Ian.

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Hans de Goede]

Hi,

On 10/04/2014 10:37 AM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>> None of the known sunxi devices actually use mmc1 routed through PH, where
>> as some devices do actually use mmc1 routed through PG, so change the routing
>> of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
>> PH, we will need to change things to be a bit more flexible.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Hmm, do you want to use your citrix address for sunxi work from now on
(fine by me), or is this a mistake ?

Regards,

Hans

[U-Boot] [PATCH 5/6] sunxi: Use PG3 - PG8 as io-pins for mmc1

[Ian Campbell]

On Mon, 2014-10-06 at 16:43 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/04/2014 10:37 AM, Ian Campbell wrote:
> > On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> >> None of the known sunxi devices actually use mmc1 routed through PH, where
> >> as some devices do actually use mmc1 routed through PG, so change the routing
> >> of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
> >> PH, we will need to change things to be a bit more flexible.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Hmm, do you want to use your citrix address for sunxi work from now on
> (fine by me), or is this a mistake ?

Oops, it's muscle memory in my fingers (since I ack an order of
magnitude patches at work...). I've always managed to catch myself in
the past...

Acked-by: Ian Campbell <ijc@hellion.org.uk>

Thanks for noticing!

Ian.

[U-Boot] [PATCH 6/6] sunxi: Enable second sdcard slot found on some boards

[Hans de Goede]

Enable the second sdcard slot found on some boards. Note that we do not
set CONFIG_MMC_SUNXI_SLOT_EXTRA for the SPL, as having it there is not useful,

Except for on the Mele-M3 where the second sdcard is an eMMC, from which the
device can also boot, and there we want to have both in the SPL, so that
a single u-boot binary can both from both. So for the M3 we do prefix the
defconfig setting with the special "+S:" syntax so that it applies to the
SPL too.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 configs/A10s-OLinuXino-M_defconfig    | 3 +++
 configs/A20-OLinuXino_MICRO_defconfig | 3 +++
 configs/Mele_M3_defconfig             | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/configs/A10s-OLinuXino-M_defconfig b/configs/A10s-OLinuXino-M_defconfig
index a578c06..f1b2d3b 100644
--- a/configs/A10s-OLinuXino-M_defconfig
+++ b/configs/A10s-OLinuXino-M_defconfig
@@ -1,5 +1,8 @@
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="A10S_OLINUXINO_M,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10)"
 CONFIG_FDTFILE="sun5i-a10s-olinuxino-micro.dtb"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=1
++S:CONFIG_MMC0_CD_PIN=193
++S:CONFIG_MMC1_CD_PIN=205
 +S:CONFIG_ARM=y
 +S:CONFIG_TARGET_SUN5I=y
diff --git a/configs/A20-OLinuXino_MICRO_defconfig b/configs/A20-OLinuXino_MICRO_defconfig
index 20a947c..17756f5 100644
--- a/configs/A20-OLinuXino_MICRO_defconfig
+++ b/configs/A20-OLinuXino_MICRO_defconfig
@@ -1,5 +1,8 @@
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="A20_OLINUXINO_M,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI"
 CONFIG_FDTFILE="sun7i-a20-olinuxino-micro.dtb"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=3
++S:CONFIG_MMC0_CD_PIN=225
++S:CONFIG_MMC3_CD_PIN=235
 +S:CONFIG_ARM=y
 +S:CONFIG_TARGET_SUN7I=y
diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig
index 645b236..50979e2 100644
--- a/configs/Mele_M3_defconfig
+++ b/configs/Mele_M3_defconfig
@@ -1,5 +1,7 @@
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI"
 CONFIG_FDTFILE="sun7i-a20-m3.dtb"
++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2
++S:CONFIG_MMC0_CD_PIN=225
 +S:CONFIG_ARM=y
 +S:CONFIG_TARGET_SUN7I=y
-- 
2.1.0

[U-Boot] [PATCH 6/6] sunxi: Enable second sdcard slot found on some boards

[Ian Campbell]

On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig
> index 645b236..50979e2 100644
> --- a/configs/Mele_M3_defconfig
> +++ b/configs/Mele_M3_defconfig
> @@ -1,5 +1,7 @@
>  CONFIG_SPL=y
>  CONFIG_SYS_EXTRA_OPTIONS="MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI"
>  CONFIG_FDTFILE="sun7i-a20-m3.dtb"
> ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2

This one is +S (regular+SPL) while the other two are just S (regular
only). Is that deliberate?

Ian.

[U-Boot] [PATCH 6/6] sunxi: Enable second sdcard slot found on some boards

[Ian Campbell]

On Sat, 2014-10-04 at 09:38 +0100, Ian Campbell wrote:
> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
> > diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig
> > index 645b236..50979e2 100644
> > --- a/configs/Mele_M3_defconfig
> > +++ b/configs/Mele_M3_defconfig
> > @@ -1,5 +1,7 @@
> >  CONFIG_SPL=y
> >  CONFIG_SYS_EXTRA_OPTIONS="MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI"
> >  CONFIG_FDTFILE="sun7i-a20-m3.dtb"
> > ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> 
> This one is +S (regular+SPL) while the other two are just S (regular
> only). Is that deliberate?

Sorry, I should have read the commit message more carefully as you
explained it quite clearly there!

This patch looks good, except insofar as some of my comments on earlier
patches could result in it looking completely different, sorry about
that!

Ian.

[U-Boot] [PATCH 6/6] sunxi: Enable second sdcard slot found on some boards

[Hans de Goede]

Hi,

On 10/04/2014 10:39 AM, Ian Campbell wrote:
> On Sat, 2014-10-04 at 09:38 +0100, Ian Campbell wrote:
>> On Fri, 2014-10-03 at 17:05 +0200, Hans de Goede wrote:
>>> diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig
>>> index 645b236..50979e2 100644
>>> --- a/configs/Mele_M3_defconfig
>>> +++ b/configs/Mele_M3_defconfig
>>> @@ -1,5 +1,7 @@
>>>  CONFIG_SPL=y
>>>  CONFIG_SYS_EXTRA_OPTIONS="MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI"
>>>  CONFIG_FDTFILE="sun7i-a20-m3.dtb"
>>> ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>>
>> This one is +S (regular+SPL) while the other two are just S (regular
>> only). Is that deliberate?
> 
> Sorry, I should have read the commit message more carefully as you
> explained it quite clearly there!
> 
> This patch looks good, except insofar as some of my comments on earlier
> patches could result in it looking completely different, sorry about
> that!

Heh, no worries. I'll try to do a v2 today addressing all your concerns.

Regards,

Hans