[U-Boot] [PATCH] imx: mx6sxsabresd: support emmc
From: Peng Fan peng.fan@nxp.com
For i.MX6SX SABRESD, USDHC4 can be used for SD and EMMC, default it is used for SD.
This patch introduces EMMC pinmux settings and a new macro CONFIG_MX6SXSABRESD_EMMC_REWORK. If the board has been reworked to support emmc, need to enable this macro.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de --- board/freescale/mx6sxsabresd/mx6sxsabresd.c | 32 +++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c b/board/freescale/mx6sxsabresd/mx6sxsabresd.c index 78f0151..6168b26 100644 --- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c +++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c @@ -109,6 +109,20 @@ static iomux_v3_cfg_t const usdhc4_pads[] = { MX6_PAD_SD4_DATA7__GPIO6_IO_21 | MUX_PAD_CTRL(NO_PAD_CTRL), };
+static iomux_v3_cfg_t const usdhc4_emmc_pads[] = { + MX6_PAD_SD4_CLK__USDHC4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_CMD__USDHC4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA0__USDHC4_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA1__USDHC4_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA2__USDHC4_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA3__USDHC4_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA4__USDHC4_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA5__USDHC4_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA6__USDHC4_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_DATA7__USDHC4_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_SD4_RESET_B__USDHC4_RESET_B | MUX_PAD_CTRL(NO_PAD_CTRL), +}; + static iomux_v3_cfg_t const fec1_pads[] = { MX6_PAD_ENET1_MDC__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL), MX6_PAD_ENET1_MDIO__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL), @@ -302,7 +316,11 @@ int board_early_init_f(void) static struct fsl_esdhc_cfg usdhc_cfg[3] = { {USDHC2_BASE_ADDR, 0, 4}, {USDHC3_BASE_ADDR}, +#ifdef CONFIG_MX6SXSABRESD_EMMC_REWORK + {USDHC4_BASE_ADDR, 0, 8}, +#else {USDHC4_BASE_ADDR}, +#endif };
#define USDHC3_CD_GPIO IMX_GPIO_NR(2, 10) @@ -327,7 +345,11 @@ int board_mmc_getcd(struct mmc *mmc) ret = !gpio_get_value(USDHC3_CD_GPIO); break; case USDHC4_BASE_ADDR: +#ifdef CONFIG_MX6SXSABRESD_EMMC_REWORK + ret = 1; +#else ret = !gpio_get_value(USDHC4_CD_GPIO); +#endif break; }
@@ -361,9 +383,14 @@ int board_mmc_init(bd_t *bis) usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK); break; case 2: +#ifdef CONFIG_MX6SXSABRESD_EMMC_REWORK + imx_iomux_v3_setup_multiple_pads( + usdhc4_emmc_pads, ARRAY_SIZE(usdhc4_emmc_pads)); +#else imx_iomux_v3_setup_multiple_pads( usdhc4_pads, ARRAY_SIZE(usdhc4_pads)); gpio_direction_input(USDHC4_CD_GPIO); +#endif usdhc_cfg[2].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK); break; default: @@ -410,9 +437,14 @@ int board_mmc_init(bd_t *bis) usdhc_cfg[0].esdhc_base = USDHC3_BASE_ADDR; break; case 3: +#ifdef CONFIG_MX6SXSABRESD_EMMC_REWORK + imx_iomux_v3_setup_multiple_pads( + usdhc4_emmc_pads, ARRAY_SIZE(usdhc4_emmc_pads)); +#else imx_iomux_v3_setup_multiple_pads( usdhc4_pads, ARRAY_SIZE(usdhc4_pads)); gpio_direction_input(USDHC4_CD_GPIO); +#endif usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK); usdhc_cfg[0].esdhc_base = USDHC4_BASE_ADDR; break;
On Tue, Dec 22, 2015 at 7:03 AM, Peng Fan van.freenix@gmail.com wrote:
From: Peng Fan peng.fan@nxp.com
For i.MX6SX SABRESD, USDHC4 can be used for SD and EMMC, default it is used for SD.
This patch introduces EMMC pinmux settings and a new macro CONFIG_MX6SXSABRESD_EMMC_REWORK. If the board has been reworked to support emmc, need to enable this macro.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de
Is it worth supporting this 'reworked' board? if someone reworks a board it is expected to have to rework the BSP of it, as well.
Hi Otavio, On Tue, Dec 22, 2015 at 09:51:37AM -0200, Otavio Salvador wrote:
On Tue, Dec 22, 2015 at 7:03 AM, Peng Fan van.freenix@gmail.com wrote:
From: Peng Fan peng.fan@nxp.com
For i.MX6SX SABRESD, USDHC4 can be used for SD and EMMC, default it is used for SD.
This patch introduces EMMC pinmux settings and a new macro CONFIG_MX6SXSABRESD_EMMC_REWORK. If the board has been reworked to support emmc, need to enable this macro.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de
Is it worth supporting this 'reworked' board? if someone reworks a board it is expected to have to rework the BSP of it, as well.
usdhc4 can be used for SD and emmc. This is the feature of the board, so I think we need to support it. But there is no way to dynamically check whether using sd or emmc now, adding the macro for using emmc.
Regards, Peng.
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Hi Peng,
On 23/12/2015 04:10, Peng Fan wrote:
Hi Otavio, On Tue, Dec 22, 2015 at 09:51:37AM -0200, Otavio Salvador wrote:
On Tue, Dec 22, 2015 at 7:03 AM, Peng Fan van.freenix@gmail.com wrote:
From: Peng Fan peng.fan@nxp.com
For i.MX6SX SABRESD, USDHC4 can be used for SD and EMMC, default it is used for SD.
This patch introduces EMMC pinmux settings and a new macro CONFIG_MX6SXSABRESD_EMMC_REWORK. If the board has been reworked to support emmc, need to enable this macro.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de
Is it worth supporting this 'reworked' board? if someone reworks a board it is expected to have to rework the BSP of it, as well.
usdhc4 can be used for SD and emmc. This is the feature of the board, so I think we need to support it. But there is no way to dynamically check whether using sd or emmc now, adding the macro for using emmc.
I agree with Otavio that this is a very nasty hack, and the hardware developer should provide a way getting the board revision. Anyway, I would not certainly block it, as it concerns just this board, but I ask if it is not better to let decide to an environment variable if eMMC must be activated. Advantage is to have a single U-Boot binary for both boards, disadvantage is that it coul be set for the wrong board revision, too. But if USDHC4 was not used anymore, this drives just to a not found eMMC. Both ways are hacks, I fully agree, but CONFIG_MX6SXSABRESD_EMMC_REWORK remains undocumented at all, too.
What do you think ?
Best regards, Stefano Babic
Hi Stefano,
On Sun, Jan 24, 2016 at 12:07:14PM +0100, Stefano Babic wrote:
Hi Peng,
On 23/12/2015 04:10, Peng Fan wrote:
Hi Otavio, On Tue, Dec 22, 2015 at 09:51:37AM -0200, Otavio Salvador wrote:
On Tue, Dec 22, 2015 at 7:03 AM, Peng Fan van.freenix@gmail.com wrote:
From: Peng Fan peng.fan@nxp.com
For i.MX6SX SABRESD, USDHC4 can be used for SD and EMMC, default it is used for SD.
This patch introduces EMMC pinmux settings and a new macro CONFIG_MX6SXSABRESD_EMMC_REWORK. If the board has been reworked to support emmc, need to enable this macro.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de
Is it worth supporting this 'reworked' board? if someone reworks a board it is expected to have to rework the BSP of it, as well.
usdhc4 can be used for SD and emmc. This is the feature of the board, so I think we need to support it. But there is no way to dynamically check whether using sd or emmc now, adding the macro for using emmc.
I agree with Otavio that this is a very nasty hack, and the hardware developer should provide a way getting the board revision. Anyway, I would not certainly block it, as it concerns just this board, but I ask if it is not better to let decide to an environment variable if eMMC must be activated. Advantage is to have a single U-Boot binary for both boards, disadvantage is that it coul be set for the wrong board revision, too. But if USDHC4 was not used anymore, this drives just to a not found eMMC. Both ways are hacks, I fully agree, but CONFIG_MX6SXSABRESD_EMMC_REWORK remains undocumented at all, too.
What do you think ?
There is no fuse bit or else to let uboot do runtime checking. I also disklike this, but I do not have a better idea. Without runtime checking, it's hard to use one image support SD/EMMC both. I would like to add doc for the macro CONFIG_MX6SXSABRESD_EMMC_REWORK in the next version, do you agree with this?
Thanks, Peng.
Best regards, Stefano Babic
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
Hi Peng,
On 24/01/2016 14:04, Peng Fan wrote:
I agree with Otavio that this is a very nasty hack, and the hardware developer should provide a way getting the board revision. Anyway, I would not certainly block it, as it concerns just this board, but I ask if it is not better to let decide to an environment variable if eMMC must be activated. Advantage is to have a single U-Boot binary for both boards, disadvantage is that it coul be set for the wrong board revision, too. But if USDHC4 was not used anymore, this drives just to a not found eMMC. Both ways are hacks, I fully agree, but CONFIG_MX6SXSABRESD_EMMC_REWORK remains undocumented at all, too.
What do you think ?
There is no fuse bit or else to let uboot do runtime checking. I also disklike this, but I do not have a better idea. Without runtime checking, it's hard to use one image support SD/EMMC both. I would like to add doc for the macro CONFIG_MX6SXSABRESD_EMMC_REWORK in the next version, do you agree with this?
I add Fabio as he is the board maintainer for mx6sxsabresd.
If adding the #ifdef remains the preferred solution instead of checkin an env variable, it should be done that it does not generate dead code as the current patch. That means that a defconfig file must be added into configs, where CONFIG_MX6SXSABRESD_EMMC_REWORK is set. Else the code is never built by running buildman and breakages cannot be detected.
Anyway, there are already two files for the board, mx6sxsabresd_defconfig and mx6sxsabresd_spl_defconfig, and if you want to have for this board revision both U-Boot with and without SPL, two additional files are needed - it does not scale very well.
Best regards, Stefano Babic
participants (3)
-
Otavio Salvador -
Peng Fan -
Stefano Babic