[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Currently when a high speed SD card is connected on MX25 or MX51 boards
the following error happens:

U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49:26 -0200)

CPU:   Freescale i.MX51 rev3.0 at 800 MHz
Reset cause: POR
Board: MX51EVK
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - read failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed

Workaround this issue by not setting the mmc high speed mode flags even
if the HOSTCAPBLT register reports that the SD card can operate at
high speed.

Tested on imx51evk and imx25pdk boards.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Kernel is capable of running the SD card at 50MHz clock, but U-Boot fails.

I haven't had a chance to debug this further, but sending it as RFC in case
someone has some suggestions.

 drivers/mmc/fsl_esdhc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index cc188c4..5ec51a2 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -850,8 +850,10 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
 			cfg->host_caps &= ~MMC_MODE_4BIT;
 	}
 
+#if !defined(CONFIG_MX25) && !defined(CONFIG_MX51)
 	if (caps & ESDHC_HOSTCAPBLT_HSS)
 		cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+#endif
 
 #ifdef CONFIG_ESDHC_DETECT_8_BIT_QUIRK
 	if (CONFIG_ESDHC_DETECT_8_BIT_QUIRK)
-- 
2.7.4

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Otavio Salvador]

On Wed, Oct 18, 2017 at 1:57 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> Currently when a high speed SD card is connected on MX25 or MX51 boards
> the following error happens:
>
> U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49:26 -0200)
>
> CPU:   Freescale i.MX51 rev3.0 at 800 MHz
> Reset cause: POR
> Board: MX51EVK
> DRAM:  512 MiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - read failed, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> => saveenv
> Saving Environment to MMC...
> Writing to MMC(0)... failed
>
> Workaround this issue by not setting the mmc high speed mode flags even
> if the HOSTCAPBLT register reports that the SD card can operate at
> high speed.
>
> Tested on imx51evk and imx25pdk boards.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>

Tested-by: Otavio Salvador <otavio@ossystems.com.br> # imx25pdk

I had this error when booting here and I can confirm it fixes the issue for me.

-- 
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

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On 18/10/2017 at 17:57, Fabio Estevam wrote:
> Currently when a high speed SD card is connected on MX25 or MX51 boards
> the following error happens:
> 
> U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49:26 -0200)
> 
> CPU:   Freescale i.MX51 rev3.0 at 800 MHz
> Reset cause: POR
> Board: MX51EVK
> DRAM:  512 MiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> *** Warning - read failed, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> => saveenv
> Saving Environment to MMC...
> Writing to MMC(0)... failed
> 
> Workaround this issue by not setting the mmc high speed mode flags even
> if the HOSTCAPBLT register reports that the SD card can operate at
> high speed.
> 
> Tested on imx51evk and imx25pdk boards.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Kernel is capable of running the SD card at 50MHz clock, but U-Boot fails.
> 
> I haven't had a chance to debug this further, but sending it as RFC in case
> someone has some suggestions.

[...]

You could stress-test the SD read/write accesses from U-Boot. Does it occur with
all HS cards?

You can try to set the drive strength of all the eSDHC pads to high or max (for
each pad or for the group of pads depending on the register layout for the pads
used on the board). This worked on my board (custom i.MX25-based, not imx25pdk).

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

On 18/10/2017 at 18:13, Benoît Thébaudeau wrote:
> Hi Fabio,
> 
> On 18/10/2017 at 17:57, Fabio Estevam wrote:
>> Currently when a high speed SD card is connected on MX25 or MX51 boards
>> the following error happens:
>>
>> U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49:26 -0200)
>>
>> CPU:   Freescale i.MX51 rev3.0 at 800 MHz
>> Reset cause: POR
>> Board: MX51EVK
>> DRAM:  512 MiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> *** Warning - read failed, using default environment
>>
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   FEC
>> Hit any key to stop autoboot:  0
>> => saveenv
>> Saving Environment to MMC...
>> Writing to MMC(0)... failed
>>
>> Workaround this issue by not setting the mmc high speed mode flags even
>> if the HOSTCAPBLT register reports that the SD card can operate at
>> high speed.
>>
>> Tested on imx51evk and imx25pdk boards.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
>> ---
>> Kernel is capable of running the SD card at 50MHz clock, but U-Boot fails.
>>
>> I haven't had a chance to debug this further, but sending it as RFC in case
>> someone has some suggestions.
> 
> [...]
> 
> You could stress-test the SD read/write accesses from U-Boot. Does it occur with
> all HS cards?
> 
> You can try to set the drive strength of all the eSDHC pads to high or max (for
> each pad or for the group of pads depending on the register layout for the pads
> used on the board). This worked on my board (custom i.MX25-based, not imx25pdk).

And set SRE to fast too.

Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Wed, Oct 18, 2017 at 2:13 PM, Benoît Thébaudeau <benoit@wsystem.com> wrote:

> You could stress-test the SD read/write accesses from U-Boot. Does it occur with
> all HS cards?

I am not able to run a stress-test because all SD card accesses fail.

It happens with all HS cards I tested with.

> You can try to set the drive strength of all the eSDHC pads to high or max (for

Looks like the eSDHC pins do not have drive strength control, only
PKE, PUE, PUS and SRE fields.

Also, in the kernel I do not do pinctrl setting and just use the IOMUX
values from U-Boot. In the kernel the SD card operation in high speed
works fine.

> each pad or for the group of pads depending on the register layout for the pads
> used on the board). This worked on my board (custom i.MX25-based, not imx25pdk).

Could you please share your custom eSDHC pinctrl settings in U-Boot?

Also, I suppose you see "Tran Speed: 50000000" when you run mmc info
with a SD high speed card connected.

In my case whenever 'mmc info' reports 50MHz I am not able to access
the SD card (saveenv, for example) on both mx25pdk and mx51evk.

Thanks

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On 18/10/2017 at 18:40, Fabio Estevam wrote:
> On Wed, Oct 18, 2017 at 2:13 PM, Benoît Thébaudeau <benoit@wsystem.com> wrote:
>> You can try to set the drive strength of all the eSDHC pads to high or max (for
> 
> Looks like the eSDHC pins do not have drive strength control, only
> PKE, PUE, PUS and SRE fields.

They may also be in a pad group control register such as
MX25_PAD_CTL_GRP_DSE_CSI.

> Also, in the kernel I do not do pinctrl setting and just use the IOMUX
> values from U-Boot. In the kernel the SD card operation in high speed
> works fine.
> 
>> each pad or for the group of pads depending on the register layout for the pads
>> used on the board). This worked on my board (custom i.MX25-based, not imx25pdk).
> 
> Could you please share your custom eSDHC pinctrl settings in U-Boot?

I can tell you what to use for imx25pdk if you give me the pads used by the
eSDHC instance in question here.

> Also, I suppose you see "Tran Speed: 50000000" when you run mmc info
> with a SD high speed card connected.

Indeed.

> In my case whenever 'mmc info' reports 50MHz I am not able to access
> the SD card (saveenv, for example) on both mx25pdk and mx51evk.

Note that I am using a modified version of U-Boot, so it may work thanks to that
for me, but the pad fixup was required anyway.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît ,

On Wed, Oct 18, 2017 at 2:56 PM, Benoît Thébaudeau <benoit@wsystem.com> wrote:

> I can tell you what to use for imx25pdk if you give me the pads used by the
> eSDHC instance in question here.

mx25pdk uses the POR default IOMUX settings for sdhc1:

static const iomux_v3_cfg_t sdhc1_pads[] = {
NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, NO_PAD_CTRL),
NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, NO_PAD_CTRL),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, NO_PAD_CTRL),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, NO_PAD_CTRL),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, NO_PAD_CTRL),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, NO_PAD_CTRL),
};

Regards,

Fabio Estevam

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Wed, Oct 18, 2017 at 7:35 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Oct 18, 2017 at 2:56 PM, Benoît Thébaudeau <benoit@wsystem.com> wrote:
>
>> I can tell you what to use for imx25pdk if you give me the pads used by the
>> eSDHC instance in question here.
>
> mx25pdk uses the POR default IOMUX settings for sdhc1:

Can you try with this?

static const iomux_v3_cfg_t sdhc1_pads[] = {
NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, PAD_CTL_PUS_47K_UP | PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, PAD_CTL_PUS_47K_UP |
PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, PAD_CTL_PUS_47K_UP |
PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, PAD_CTL_PUS_47K_UP |
PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, PAD_CTL_PUS_47K_UP |
PAD_CTL_SRE_FAST),
NEW_PAD_CTRL(MX25_PAD_CTL_GRP_DSE_SDHC1, PAD_CTL_DSE_HIGH),
};

If you scope the SD clock during U-Boot HS SD transfers, do you get 48
MHz as expected?

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Wed, Oct 18, 2017 at 6:10 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> Can you try with this?
>
> static const iomux_v3_cfg_t sdhc1_pads[] = {
> NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, PAD_CTL_PUS_47K_UP | PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_CTL_GRP_DSE_SDHC1, PAD_CTL_DSE_HIGH),
> };
>
> If you scope the SD clock during U-Boot HS SD transfers, do you get 48
> MHz as expected?

I will try tomorrow when I have access to the mx25pdk board again.

Thanks!

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Wed, Oct 18, 2017 at 6:10 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> Can you try with this?
>
> static const iomux_v3_cfg_t sdhc1_pads[] = {
> NEW_PAD_CTRL(MX25_PAD_SD1_CMD__SD1_CMD, PAD_CTL_PUS_47K_UP | PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_CLK__SD1_CLK, PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA0__SD1_DATA0, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA1__SD1_DATA1, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA2__SD1_DATA2, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_SD1_DATA3__SD1_DATA3, PAD_CTL_PUS_47K_UP |
> PAD_CTL_SRE_FAST),
> NEW_PAD_CTRL(MX25_PAD_CTL_GRP_DSE_SDHC1, PAD_CTL_DSE_HIGH),
> };

Unfortunately it does not help. Same error:

U-Boot 2017.11-rc2-00001-g1f16d26-dirty (Oct 19 2017 - 09:47:25 -0200)

CPU:   Freescale i.MX25 rev1.2 at 399 MHz
Reset cause: POR
Board: MX25PDK
I2C:   ready
DRAM:  64 MiB
No arch specific invalidate_icache_all available!
MMC:   FSL_SDHC: 0
*** Warning - read failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed
=>

I don't think it is an IOMUX issue as the kernel has no issues in with
SD high speed card and it uses the same IOMUX settings from U-Boot.

> If you scope the SD clock during U-Boot HS SD transfers, do you get 48
> MHz as expected?

I do see 48MHz.

I would be interested to see if you can get an SD card high speed to
work with mainline U-Boot on your board.

On my tests I need to force it 25MHz operation to be able to use the SD card.

Thanks

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

On Thu, Oct 19, 2017 at 9:57 AM, Fabio Estevam <festevam@gmail.com> wrote:

> On my tests I need to force it 25MHz operation to be able to use the SD card.

A "less ugly" workaround that affects only mx25pdk:

--- a/board/freescale/mx25pdk/mx25pdk.c
+++ b/board/freescale/mx25pdk/mx25pdk.c
@@ -180,7 +180,7 @@ int board_mmc_init(bd_t *bis)
         * to 50 MHz that can be obtained, which requires to use UPLL as the
         * clock source. This actually gives 48 MHz.
         */
-       imx_set_perclk(MXC_ESDHC1_CLK, true, 50000000);
+       imx_set_perclk(MXC_ESDHC1_CLK, true, 25000000);
        esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
        return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
 }

For mx51evk this also fixes the issue:

diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 9e8a02e..72b09b5 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -323,7 +323,7 @@ int board_mmc_init(bd_t *bis)
        u32 index;
        int ret;

-       esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+       esdhc_cfg[0].sdhc_clk = 25000000;
        esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);

        for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM;

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Otavio Salvador]

On Thu, Oct 19, 2017 at 10:42 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Oct 19, 2017 at 9:57 AM, Fabio Estevam <festevam@gmail.com> wrote:
>
>> On my tests I need to force it 25MHz operation to be able to use the SD card.
>
> A "less ugly" workaround that affects only mx25pdk:
>
> --- a/board/freescale/mx25pdk/mx25pdk.c
> +++ b/board/freescale/mx25pdk/mx25pdk.c
> @@ -180,7 +180,7 @@ int board_mmc_init(bd_t *bis)
>          * to 50 MHz that can be obtained, which requires to use UPLL as the
>          * clock source. This actually gives 48 MHz.
>          */
> -       imx_set_perclk(MXC_ESDHC1_CLK, true, 50000000);
> +       imx_set_perclk(MXC_ESDHC1_CLK, true, 25000000);
>         esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
>         return fsl_esdhc_initialize(bis, &esdhc_cfg[0]);
>  }
>
> For mx51evk this also fixes the issue:
>
> diff --git a/board/freescale/mx51evk/mx51evk.c
> b/board/freescale/mx51evk/mx51evk.c
> index 9e8a02e..72b09b5 100644
> --- a/board/freescale/mx51evk/mx51evk.c
> +++ b/board/freescale/mx51evk/mx51evk.c
> @@ -323,7 +323,7 @@ int board_mmc_init(bd_t *bis)
>         u32 index;
>         int ret;
>
> -       esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
> +       esdhc_cfg[0].sdhc_clk = 25000000;
>         esdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
>
>         for (index = 0; index < CONFIG_SYS_FSL_ESDHC_NUM;

I think the original RFC is better as workaround as it solves the
issue for other boards. This does not mean we shouldn't fix the root
cause ...

-- 
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

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

On Thu, Oct 19, 2017 at 10:46 AM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:

> I think the original RFC is better as workaround as it solves the
> issue for other boards. This does not mean we shouldn't fix the root
> cause ...

Actually I don't know if this issue happens with other mx25/mx51 boards.

Benoit says his mx25 board can operate with high speed SD card in a
modified version of U-Boot.
I asked him if he could test his board with mainline U-Boot instead
for comparison.

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

On 19/10/2017 at 14:52, Fabio Estevam wrote:
> On Thu, Oct 19, 2017 at 10:46 AM, Otavio Salvador
> <otavio.salvador@ossystems.com.br> wrote:
> 
>> I think the original RFC is better as workaround as it solves the
>> issue for other boards. This does not mean we shouldn't fix the root
>> cause ...
> 
> Actually I don't know if this issue happens with other mx25/mx51 boards.
> 
> Benoit says his mx25 board can operate with high speed SD card in a
> modified version of U-Boot.
> I asked him if he could test his board with mainline U-Boot instead
> for comparison.

I will try to quickly run mainline U-Boot on my board as asked to see.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On 19/10/2017 at 13:57, Fabio Estevam wrote:
> 
> I would be interested to see if you can get an SD card high speed to
> work with mainline U-Boot on your board.
> 
> On my tests I need to force it 25MHz operation to be able to use the SD card.

With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS
ones. Both types of cards work fine at 48 MHz with my custom and older U-Boot.

The main difference seems to be the management of SD timeouts. I will try to
track the differences until I find the root cause. The test results in PIO mode
might also give some clues.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Fri, Oct 20, 2017 at 10:40 AM, Benoît Thébaudeau <benoit@wsystem.com> wrote:

> With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS
> ones. Both types of cards work fine at 48 MHz with my custom and older U-Boot.

Ok, great! What is the version of your old U-Boot?

>
> The main difference seems to be the management of SD timeouts. I will try to
> track the differences until I find the root cause. The test results in PIO mode
> might also give some clues.

Thanks for the investigation!

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Fri, Oct 20, 2017 at 8:40 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Oct 20, 2017 at 10:40 AM, Benoît Thébaudeau <benoit@wsystem.com> wrote:
>
>> With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS
>> ones. Both types of cards work fine at 48 MHz with my custom and older U-Boot.
>
> Ok, great! What is the version of your old U-Boot?

2012.07. I know, _very_ old.

About the drive strength, the CSI pads used on my board for eSDHC2
have their drive strength set to nominal after POR, and I had to set
it to high in order to make HS work, whereas the SD1 pads used on
mx25pdk for eSDHC1 already have their default drive strength set to
high, so setting it to max as I previously suggested should not be
needed, unless the routing of the board requires it and there are also
errors in Linux that are just silently recovered.

>> The main difference seems to be the management of SD timeouts. I will try to
>> track the differences until I find the root cause. The test results in PIO mode
>> might also give some clues.
>
> Thanks for the investigation!

I already have a mainline version working at HS with changes only in
fsl_esdhc.c (apart from the port of my board). I still have to narrow
these changes down to the issue.

Is it mainline Linux that you have tested?

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> I already have a mainline version working at HS with changes only in
> fsl_esdhc.c (apart from the port of my board). I still have to narrow
> these changes down to the issue.

Ok, great!

> Is it mainline Linux that you have tested?

Yes, kernel 4.13.x

Thanks

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Sat, Oct 21, 2017 at 2:38 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
>
>> I already have a mainline version working at HS with changes only in
>> fsl_esdhc.c (apart from the port of my board). I still have to narrow
>> these changes down to the issue.
>
> Ok, great!

The issue is the timeout in esdhc_setup_data() on line 309. If I
revert e978a31b and fb823981, then everything works fine. However, the
latest calculation is correct, so reverting these commits is not the
fix. Indeed, for HS transfers:
mmc->tran_speed = 50000000, fls(mmc->tran_speed/4) = 24
mmc->clock = 48000000, fls(mmc->clock/2) = 25
I've tested with 26 and 27, and they work fine. Therefore,
SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an
undocumented erratum, which could just happen to be
CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum,
then a new workaround could be implemented for it, or
ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask
your design team to confirm this?

Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to
be defined in a SoC header file (such as
arch/arm/include/asm/arch-mx25/imx-regs.h) or in
drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected
from the configuration, rather than keeping it as a configuration
setting to be defined in a board configuration file (such as
include/configs/mx25pdk.h)?

Note that it would be possible to go further than fb823981 to optimize
this timeout because mmc->clock is also not always the actual SD clock
frequency resulting from set_sysctl(). However, timeout cases should
normally never occur, so optimizing them is a bit pointless.

Note that mainline Linux always uses the maximum timeout regardless of
the SD clock frequency.

I've also noticed that the PIO mode fails (even with the commits above
reverted) for write accesses (read accesses work fine) with "Data
Write Failed in PIO Mode.". I have not investigated this issue yet.
This is also related to a timeout, but the root cause could be
somewhere else, e.g. in the changes introduced in esdhc_setup_data()
for the PIO mode.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> The issue is the timeout in esdhc_setup_data() on line 309. If I
> revert e978a31b and fb823981, then everything works fine. However, the
> latest calculation is correct, so reverting these commits is not the
> fix. Indeed, for HS transfers:
> mmc->tran_speed = 50000000, fls(mmc->tran_speed/4) = 24
> mmc->clock = 48000000, fls(mmc->clock/2) = 25
> I've tested with 26 and 27, and they work fine. Therefore,
> SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an
> undocumented erratum, which could just happen to be
> CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum,
> then a new workaround could be implemented for it, or
> ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask
> your design team to confirm this?

I can try to ask it internally when I am back to the office next week.

> Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to
> be defined in a SoC header file (such as
> arch/arm/include/asm/arch-mx25/imx-regs.h) or in
> drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected
> from the configuration, rather than keeping it as a configuration
> setting to be defined in a board configuration file (such as
> include/configs/mx25pdk.h)?
>
> Note that it would be possible to go further than fb823981 to optimize
> this timeout because mmc->clock is also not always the actual SD clock
> frequency resulting from set_sysctl(). However, timeout cases should
> normally never occur, so optimizing them is a bit pointless.
>
> Note that mainline Linux always uses the maximum timeout regardless of
> the SD clock frequency.

Can we also do like this in U-Boot for now?

Thanks

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Tue, Oct 24, 2017 at 10:50 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
>
>> The issue is the timeout in esdhc_setup_data() on line 309. If I
>> revert e978a31b and fb823981, then everything works fine. However, the
>> latest calculation is correct, so reverting these commits is not the
>> fix. Indeed, for HS transfers:
>> mmc->tran_speed = 50000000, fls(mmc->tran_speed/4) = 24
>> mmc->clock = 48000000, fls(mmc->clock/2) = 25
>> I've tested with 26 and 27, and they work fine. Therefore,
>> SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an
>> undocumented erratum, which could just happen to be
>> CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum,
>> then a new workaround could be implemented for it, or
>> ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask
>> your design team to confirm this?
>
> I can try to ask it internally when I am back to the office next week.
>
>> Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to
>> be defined in a SoC header file (such as
>> arch/arm/include/asm/arch-mx25/imx-regs.h) or in
>> drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected
>> from the configuration, rather than keeping it as a configuration
>> setting to be defined in a board configuration file (such as
>> include/configs/mx25pdk.h)?
>>
>> Note that it would be possible to go further than fb823981 to optimize
>> this timeout because mmc->clock is also not always the actual SD clock
>> frequency resulting from set_sysctl(). However, timeout cases should
>> normally never occur, so optimizing them is a bit pointless.
>>
>> Note that mainline Linux always uses the maximum timeout regardless of
>> the SD clock frequency.
>
> Can we also do like this in U-Boot for now?

Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be
the most optimal approach here, so I'll wait for the answer from your
design team before doing anything.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît ,

On Sun, Oct 29, 2017 at 7:18 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be
> the most optimal approach here, so I'll wait for the answer from your
> design team before doing anything.

I have just asked them to confirm.

This is the same issue Sebastien fixed some time ago:
https://lists.denx.de/pipermail/u-boot/2016-April/252497.html

Hopefully we can receive a confirmation prior to the 2017.11 release.

Thanks

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

Hi Benoît,

On Sun, Oct 29, 2017 at 7:18 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be
> the most optimal approach here, so I'll wait for the answer from your
> design team before doing anything.

I received the confirmation that ESDHC_A001 also affects mx25 and mx51
and set a patch series to select this erratum on these SoCs.

Thanks a lot for your help in debugging this problem. Really appreciated!

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Fri, Nov 3, 2017 at 4:17 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Sun, Oct 29, 2017 at 7:18 PM, Benoît Thébaudeau
> <benoit.thebaudeau.dev@gmail.com> wrote:
>
>> Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be
>> the most optimal approach here, so I'll wait for the answer from your
>> design team before doing anything.
>
> I received the confirmation that ESDHC_A001 also affects mx25 and mx51
> and set a patch series to select this erratum on these SoCs.

Thanks. If NXP could update the corresponding errata sheets, that
would be great.

> Thanks a lot for your help in debugging this problem. Really appreciated!

You're welcome.

Best regards,
Benoît

[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Fabio Estevam]

On Fri, Nov 3, 2017 at 7:25 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@gmail.com> wrote:

> Thanks. If NXP could update the corresponding errata sheets, that
> would be great.

Agreed. I will check with them.

Regards,

Fabio Estevam