Tool/software:
My customer has partial board eMMC HS200 stability of copy larger file in Linux fail. with patch form this thread can fix the failure board.
In SDK10.01 release noted stated the copy larger file fail issue resolved. then compared the patch to relative files of SDK9.2, SDK10.0 and SDK10.1, summary and questions as below:
#1. Before SDK10.1, UBOOT and Kernel dtsi sdhci0 parameters all use same parameters, but doesn't follow datasheet.
sdhci0: mmc@fa10000 {
compatible = "ti,am62-sdhci";
reg = <0x00 0x0fa10000 0x00 0x1000>, <0x00 0x0fa18000 0x00 0x400>;
interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 57 5>, <&k3_clks 57 6>;
clock-names = "clk_ahb", "clk_xin";
assigned-clocks = <&k3_clks 57 6>;
assigned-clock-parents = <&k3_clks 57 8>;
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
ti,clkbuf-sel = <0x7>;
ti,otap-del-sel-legacy = <0x0>;
ti,otap-del-sel-mmc-hs = <0x0>;
ti,otap-del-sel-ddr52 = <0x5>;
ti,otap-del-sel-hs200 = <0x5>;
ti,itap-del-sel-legacy = <0xa>;
ti,itap-del-sel-mmc-hs = <0x1>;
status = "disabled";
};
#2. In SDK10.1, UBOOT still use upper/old parameter. Kernel dts updated as below to follow datasheet.
Questions:
#2.1 Why UBOOT use different tap delay parameter which doesn't follow datasheet but still can work at HS200.
#2.2. Why Linux must use tap delay value as datasheet, is it the major factor fixed the issue? or just update it to follow datasheet? but forgot to update UBOOT dts fil？
sdhci0: mmc@fa10000 {
compatible = "ti,am62-sdhci";
reg = <0x00 0x0fa10000 0x00 0x1000>, <0x00 0x0fa18000 0x00 0x400>;
interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 57 5>, <&k3_clks 57 6>;
clock-names = "clk_ahb", "clk_xin";
assigned-clocks = <&k3_clks 57 6>;
assigned-clock-parents = <&k3_clks 57 8>;
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
ti,clkbuf-sel = <0x7>;
ti,otap-del-sel-legacy = <0x0>;
ti,otap-del-sel-mmc-hs = <0x0>;
ti,otap-del-sel-hs200 = <0x6>;
ti,itap-del-sel-legacy = <0x0>;
ti,itap-del-sel-mmc-hs = <0x0>;
status = "disabled";
};
#3. There are some change in drivers/mmc/host/sdhci_am654.c, but did not find below change in SDK10.1 compare to the patch in upper thread, is this patch not required actually?
static u8 sdhci_am654_write_power_on(struct sdhci_host *host, u8 val, int reg)
{
writeb(val, host->ioaddr + reg);
@@ -706,6 +753,12 @@ static int sdhci_am654_init(struct sdhci_host *host)
u32 mask;
u32 val;
int ret;
+ u16 ctrl;
+
+ /* Unset CTRL_VDD_180 */
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ ctrl &= ~SDHCI_CTRL_VDD_180;
+ sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
#4. sdhci_am654.c, the major change is adding sdhci_am654_start_signal_voltage_switch() call. What problem was fixed by this change?
#5. From the upper thread, change the serial resistors can help the problem. originally it is 33ohm, some board can't boot. then change to 22ohm, can boot.
#6. With patch, no matter the resistor is 33ohm, 22ohm, or 0ohm, all can boot up. Seems the patch effects more than hardware factors.
So need clarification about the driver change.
