| Message ID | 1508342223-12334-1-git-send-email-fabio.estevam@nxp.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | [U-Boot,RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51 | expand |
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.
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
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
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
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
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
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
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!
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
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;
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 ...
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.
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
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
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!
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
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
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
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
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
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
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!
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
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
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)
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(+)