[U-Boot] [PATCH 0/6] sunxi: Add second sdcard slot support, including eMMC boot
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
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)
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.
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
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)
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.
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
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
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
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
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.
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]); }
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.
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
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
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
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); }
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.
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
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.
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
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.
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
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.
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.
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
participants (2)
-
Hans de Goede -
Ian Campbell