sunxi: Add second sdcard slot support, including eMMC boot
Subsystems (3)
cover 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
PATCH 1/6 sunxi: Add sunxi_gpio_get_val function
--- arch/arm/cpu/armv7/sunxi/pinmux.c | 13 +++++++++++++ arch/arm/include/asm/arch-sunxi/gpio.h | 1 + 2 files changed, 14 insertions(+)
arch/arm/cpu/armv7/sunxi/pinmux.c +13 -0
@@ -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 ; +}
arch/arm/include/asm/arch-sunxi/gpio.h +1 -0
@@ -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)
Signature · 1 line
2.1.0
PATCH 1/6 sunxi: Add sunxi_gpio_get_val function
Quoted 1 line · Hans de Goede
Signed-off-by Hans de Goede <[email protected]>
drivers/gpio/sunxi_gpio.c already has sunxi_gpio_input exported via the standard gpio_get_value name.
Ian.
PATCH 1/6 sunxi: Add sunxi_gpio_get_val function
Hi Ian,
Thanks for the reviews!
Quoted 5 lines · Ian Campbell
Quoted 1 line · Hans de Goede
Signed-off-by Hans de Goede <[email protected]>
drivers/gpio/sunxi_gpio.calready hassunxi_gpio_inputexported via the standardgpio_get_valuename.
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
PATCH 2/6 sunxi: Add mmc card-detect functionality
In reply to Hans de Goede--- board/sunxi/Kconfig | 27 +++++++++++++++++++++++++++ drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++ 2 files changed, 47 insertions(+)
board/sunxi/Kconfig +27 -0
@@ -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
drivers/mmc/sunxi_mmc.c +20 -0
@@ -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)
Signature · 1 line
2.1.0
PATCH 2/6 sunxi: Add mmc card-detect functionality
Quoted 12 lines · Hans de Goede
Signed-off-by Hans de Goede <[email protected]>--- board/sunxi/Kconfig | 27 +++++++++++++++++++++++++++ drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++ 2 files changed, 47 insertions(+)board/sunxi/Kconfig +0
-0@@ -32,4 +32,31 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically used
board/sunxi/Kconfig config USB_KEYBOARD · line 42
Quoted 10 lines
board/sunxi/Kconfig +8
-0in 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.
PATCH 2/6 sunxi: Add mmc card-detect functionality
Hi,
Quoted 29 lines · Ian Campbell
Quoted 12 lines · Hans de Goede
Signed-off-by Hans de Goede <[email protected]>--- board/sunxi/Kconfig | 27 +++++++++++++++++++++++++++ drivers/mmc/sunxi_mmc.c | 20 ++++++++++++++++++++ 2 files changed, 47 insertions(+)board/sunxi/Kconfig +0
-0@@ -32,4 +32,31 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically usedboard/sunxi/Kconfig config USB_KEYBOARD · line 42
Quoted 10 lines
board/sunxi/Kconfig +8
-0in 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
Kconfigand cpp trickery?
Quoted 3 lines
Maybe the simplest solution is to make this a string and pass it to
name_to_gpioat 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
PATCH 3/6 sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
In reply to Hans de GoedeNote 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.
--- board/sunxi/Kconfig | 8 ++++++++ board/sunxi/board.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
board/sunxi/Kconfig +8 -0
@@ -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
board/sunxi/board.c +1 -1
@@ -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
Signature · 1 line
2.1.0
PATCH 3/6 sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
Quoted 5 lines · 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 <[email protected]>
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?
Quoted 37 lines
--- board/sunxi/Kconfig | 8 ++++++++ board/sunxi/board.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)board/sunxi/Kconfig +8
-0@@ -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 -1board/sunxi/board.c +1
-1@@ -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
PATCH 3/6 sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
Hi,
Quoted 10 lines · Ian Campbell
Quoted 5 lines · 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 <[email protected]>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
Quoted 40 lines
Quoted 38 lines
--- board/sunxi/Kconfig | 8 ++++++++ board/sunxi/board.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)board/sunxi/Kconfig +8
-0@@ -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 -1board/sunxi/board.c +1
-1@@ -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
PATCH 3/6 sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
Quoted 10 lines · Hans de Goede
Hi,
Quoted 7 lines · Ian Campbell
Quoted 5 lines · 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 <[email protected]>
Quoted 8 lines
Quoted 3 lines
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.
PATCH 4/6 sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
In reply to Hans de Goedesunxi 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.
--- 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(-)
arch/arm/include/asm/arch-sunxi/mmc.h +1 -1
@@ -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 */
board/sunxi/board.c +23 -2
@@ -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 ;
drivers/mmc/sunxi_mmc.c +2 -5
@@ -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]); }
Signature · 1 line
2.1.0
PATCH 4/6 sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
Quoted 3 lines · 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.
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?
board/sunxi/board.c static void mmc_pinmux_setup(int sdc) · line 131
Quoted 10 lines
board/sunxi/board.c +10
-0+#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.
PATCH 4/6 sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
Quoted 7 lines · Ian Campbell
Quoted 3 lines · 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.
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.
Quoted 5 lines
If it's just that then is it allowable to define
CONFIG_SYS_MMC_ENV_DEVas a call to a function which returns the appropriate number?Or maybe
mmc->block_dev.devalready 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.
Quoted 5 lines
Quoted 5 lines
board/sunxi/board.c +5
-0+#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. +*/
Quoted 8 lines
board/sunxi/board.c static void mmc_pinmux_setup(int sdc) · line 131
Quoted 5 lines
board/sunxi/board.c +5
-0+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.
Quoted 2 lines
Or is "just like the brom does" implying that the bootrom would always have booted mmc0 if this signature was there?
Yes.
Quoted 2 lines
is that check sufficient or does the brom check other stuff, e.g. signatures etc.
AFAIK that check is all it does.
Quoted 1 line
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
PATCH 4/6 sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
Quoted 10 lines · Hans de Goede
Quoted 7 lines · Ian Campbell
Quoted 3 lines · 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.
Where does the dependency on dev 0 being the boot device come from? Is it just the env via
CONFIG_SYS_MMC_ENV_DEV?
Quoted 7 lines
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.cWhich 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)
Quoted 7 lines
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
PATCH 4/6 sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
Hi,
Quoted 15 lines · Ian Campbell
Quoted 14 lines · Hans de Goede
Quoted 7 lines · Ian Campbell
Quoted 3 lines · 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.
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:
Quoted 6 lines
Quoted 3 lines
common/spl/spl_mmc.cWhich 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
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
In reply to Hans de GoedeNone 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.
--- arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++ board/sunxi/board.c | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-)
arch/arm/include/asm/arch-sunxi/gpio.h +2 -0
@@ -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
board/sunxi/board.c +3 -3
@@ -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 ); }
Signature · 1 line
2.1.0
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
Quoted 6 lines · 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 <[email protected]>
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.
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
Hi,
Quoted 6 lines · Ian Campbell
Quoted 5 lines · 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.
Quoted 6 lines
Quoted 1 line
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>Although it seems that adding a
Kconfigchoice 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
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
Quoted 16 lines · Hans de Goede
Hi,
Quoted 6 lines · Ian Campbell
Quoted 5 lines · 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.
Quoted 6 lines
Quoted 1 line
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>Although it seems that adding a
Kconfigchoice option would only be a dozen or so lines of pretty trivial stuff if we wanted to do it now.
Quoted 8 lines
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.
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
In reply to Ian CampbellHi,
Quoted 9 lines · Ian Campbell
Quoted 6 lines · 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 <[email protected]>Acked-by Ian Campbell <[email protected]>
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
PATCH 5/6 sunxi: Use PG3 - PG8 as io-pins for mmc1
Quoted 9 lines · Hans de Goede
Hi,
Quoted 6 lines · Ian Campbell
Quoted 5 lines · 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.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Hans de Goede <[email protected]>Acked-by Ian Campbell <[email protected]>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...
Thanks for noticing!
Ian.
PATCH 6/6 sunxi: Enable second sdcard slot found on some boards
In reply to Hans de GoedeEnable 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.
--- configs/A10s-OLinuXino-M_defconfig | 3 +++ configs/A20-OLinuXino_MICRO_defconfig | 3 +++ configs/Mele_M3_defconfig | 2 ++ 3 files changed, 8 insertions(+)
configs/A10s-OLinuXino-M_defconfig +3 -0
@@ -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
configs/A20-OLinuXino_MICRO_defconfig +3 -0
@@ -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
configs/Mele_M3_defconfig +2 -0
@@ -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
Signature · 1 line
2.1.0
PATCH 6/6 sunxi: Enable second sdcard slot found on some boards
configs/Mele_M3_defconfig line 4
Quoted 9 lines · Hans de Goede
configs/Mele_M3_defconfig +1
-0@@ -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.
PATCH 6/6 sunxi: Enable second sdcard slot found on some boards
Quoted 13 lines · Ian Campbell
configs/Mele_M3_defconfig line 4
Quoted 9 lines · Hans de Goede
configs/Mele_M3_defconfig +1
-0@@ -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=2This 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.
PATCH 6/6 sunxi: Enable second sdcard slot found on some boards
Hi,
Quoted 15 lines · Ian Campbell
Quoted 13 lines · Ian Campbell
configs/Mele_M3_defconfig line 4
Quoted 9 lines · Hans de Goede
configs/Mele_M3_defconfig +1
-0@@ -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=2This one is +S (regular+SPL) while the other two are just S (regular only). Is that deliberate?
Quoted 6 lines
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