[PATCH] sunxi-mmc: increase stabilization delay from 1ms to 20ms
Some users experienced problems booting u-boot from SPL hanging here:
Trying to boot from MMC1 or Trying to boot from MMC2
This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC. Increasing the delay after mmc reset fixes these boot problems. Some MicroSD cards are impacted more than others so it is possible that MicroSD internals need time to stabilize. Below is some failure data.
sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
A quick comparison of schematics show series resistors for ESD protection on the MicroSD GPIOs not present on all H3/H5 boards. It is not known if this is related to the issue.
This patch adds a fixed 20ms delay to mmc init to mitigate the problem. If boot time optimization is required and the platform does not require the delay. The delay can be replaced with:
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); if (wait_for_bit_le32( &priv->reg->gctrl, SUNXI_MMC_GCTRL_RESET, false, 20, false)) { printf("%s: Timeout\n", __func__); return -ETIMEDOUT; }
Signed-off-by: Da Xue da@libre.computer --- drivers/mmc/sunxi_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 1bb7b6d0e9..f7942b69ce 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
/* Reset controller */ writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); - udelay(1000); + udelay(20000);
return 0; }
On 21/07/2022 23:08, Da Xue wrote:
Hi,
Some users experienced problems booting u-boot from SPL hanging here:
Trying to boot from MMC1 or Trying to boot from MMC2
This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC. Increasing the delay after mmc reset fixes these boot problems. Some MicroSD cards are impacted more than others so it is possible that MicroSD internals need time to stabilize. Below is some failure data.
sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
A quick comparison of schematics show series resistors for ESD protection on the MicroSD GPIOs not present on all H3/H5 boards. It is not known if this is related to the issue.
This patch adds a fixed 20ms delay to mmc init to mitigate the problem. If boot time optimization is required and the platform does not require the delay. The delay can be replaced with:
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); if (wait_for_bit_le32( &priv->reg->gctrl, SUNXI_MMC_GCTRL_RESET, false, 20, false)) { printf("%s: Timeout\n", __func__); return -ETIMEDOUT; }
So what about adding this for everyone (we should have it regardless) then?
And then have an extra Kconfig option to specify an extra delay, and define this only in your board defconfig? Because IIUC this is specific to your board?
And as I mentioned: it looks odd to have this here and have it fixing your SD card problems: - The soft reset should reset just the internal controller logic (MMC state machine and FIFOs), this shouldn't affect cards. IIUC, nothing should happen on the MMC *pins* because of this operation. - Why isn't this a problem for U-Boot proper, and Linux, FWIW?
Cheers, Andre
Signed-off-by: Da Xue da@libre.computer
drivers/mmc/sunxi_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 1bb7b6d0e9..f7942b69ce 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
/* Reset controller */ writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
- udelay(1000);
udelay(20000);
return 0; }
Dne petek, 22. julij 2022 ob 18:55:14 CEST je Andre Przywara napisal(a):
On 21/07/2022 23:08, Da Xue wrote:
Hi,
Some users experienced problems booting u-boot from SPL hanging here:
Trying to boot from MMC1 or Trying to boot from MMC2
This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC. Increasing the delay after mmc reset fixes these boot problems. Some MicroSD cards are impacted more than others so it is possible that MicroSD internals need time to stabilize. Below is some failure data.
sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
A quick comparison of schematics show series resistors for ESD protection on the MicroSD GPIOs not present on all H3/H5 boards. It is not known if this is related to the issue.
This patch adds a fixed 20ms delay to mmc init to mitigate the problem. If boot time optimization is required and the platform does not require the delay. The delay can be replaced with:
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); if (wait_for_bit_le32( &priv->reg->gctrl, SUNXI_MMC_GCTRL_RESET, false, 20, false)) { printf("%s: Timeout\n", __func__); return -ETIMEDOUT; }
So what about adding this for everyone (we should have it regardless) then?
And then have an extra Kconfig option to specify an extra delay, and define this only in your board defconfig? Because IIUC this is specific to your board?
And as I mentioned: it looks odd to have this here and have it fixing your SD card problems:
- The soft reset should reset just the internal controller logic (MMC
state machine and FIFOs), this shouldn't affect cards. IIUC, nothing should happen on the MMC *pins* because of this operation.
- Why isn't this a problem for U-Boot proper, and Linux, FWIW?
As I said before, I have issue only at cold boot in SPL. Once I pass this point, it works all the time, even if rebooted. Why is that so it's unclear.
Thinking about this a bit, I have another question. How is it possible that BROM manages to read SD card just fine and loads SPL beforehand? Is it using lower speed? It also couldn't be power issue, since card must have been properly powered up by BROM...
Best regards, Jernej
Cheers, Andre
Signed-off-by: Da Xue da@libre.computer
drivers/mmc/sunxi_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 1bb7b6d0e9..f7942b69ce 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
/* Reset controller */ writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
- udelay(1000);
udelay(20000);
return 0;
}
On Fri, Jul 22, 2022 at 1:56 PM Jernej Škrabec jernej.skrabec@gmail.com wrote:
Dne petek, 22. julij 2022 ob 18:55:14 CEST je Andre Przywara napisal(a):
On 21/07/2022 23:08, Da Xue wrote:
Hi,
Some users experienced problems booting u-boot from SPL hanging here:
Trying to boot from MMC1 or Trying to boot from MMC2
This seems to occur with both MicroSD and eMMC modules on ALL-H3-CC. Increasing the delay after mmc reset fixes these boot problems. Some MicroSD cards are impacted more than others so it is possible that MicroSD internals need time to stabilize. Below is some failure data.
sandisk ultra 64gb 9/20 with 1ms, 20/20 with 10ms sandisk ultra 16gb 2/20 with 1ms, 20/20 with 10ms sandisk extreme 16gb 6/20 with 10ms, 20/20 with 20ms
A quick comparison of schematics show series resistors for ESD protection on the MicroSD GPIOs not present on all H3/H5 boards. It is not known if this is related to the issue.
This patch adds a fixed 20ms delay to mmc init to mitigate the problem. If boot time optimization is required and the platform does not require the delay. The delay can be replaced with:
writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl); if (wait_for_bit_le32( &priv->reg->gctrl, SUNXI_MMC_GCTRL_RESET, false, 20, false)) { printf("%s: Timeout\n", __func__); return -ETIMEDOUT; }
So what about adding this for everyone (we should have it regardless) then?
I think it would be good to add for everyone. This only happens in SPL so the impact is limited in terms of time cost.
And then have an extra Kconfig option to specify an extra delay, and define this only in your board defconfig? Because IIUC this is specific to your board?
I only have my boards to test. I'm sure there are other devices that have the same issue. I don't think it's exclusive to our boards.
And as I mentioned: it looks odd to have this here and have it fixing your SD card problems:
- The soft reset should reset just the internal controller logic (MMC
state machine and FIFOs), this shouldn't affect cards. IIUC, nothing should happen on the MMC *pins* because of this operation.
- Why isn't this a problem for U-Boot proper, and Linux, FWIW?
As I said before, I have issue only at cold boot in SPL. Once I pass this point, it works all the time, even if rebooted. Why is that so it's unclear.
Thinking about this a bit, I have another question. How is it possible that BROM manages to read SD card just fine and loads SPL beforehand? Is it using lower speed? It also couldn't be power issue, since card must have been properly powered up by BROM...
Is the bootrom using SPI mode on first boot? If that is the case, a transition would take time and may explain the necessity of this.
Best regards, Jernej
Cheers, Andre
Signed-off-by: Da Xue da@libre.computer
drivers/mmc/sunxi_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 1bb7b6d0e9..f7942b69ce 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -297,7 +297,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
/* Reset controller */ writel(SUNXI_MMC_GCTRL_RESET, &priv->reg->gctrl);
- udelay(1000);
udelay(20000);
return 0;
}
participants (3)
-
Andre Przywara -
Da Xue -
Jernej Škrabec