| Message ID | 20240204205312.2342868-2-jonas@kwiboo.se |
|---|---|
| State | Accepted |
| Commit | ebe293bae79d8c64d9cd4284044e25ddadd074b5 |
| Delegated to: | Kever Yang |
| Headers | show |
| Series | rockchip: rk35xx: Fix writing to eMMC | expand |
On 2024/2/5 04:53, Jonas Karlman wrote: > Testing has shown that writing to eMMC using DDR52 mode does not seem to > work on RK356x and RK3588 boards. > > A simple test of writing a single block to e.g. sector 0x4000 fails: > > # Rescan using DDR52 mode > => mmc rescan 4 > > # Write a single block to sector 0x4000 fails with ERROR > => mmc write 20000000 4000 1 > > With the MMC_SPEED_MODE_SET Kconfig option enabled. > > Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected > board u-boot.dtsi files. > > Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Thanks, - Kever > --- > Changes in v2: > - Update commit message > > Link to v1: https://patchwork.ozlabs.org/patch/1891695/ > --- > arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - > arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - > 12 files changed, 12 deletions(-) > > diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > index 11976fd3a6e0..930d660868bb 100644 > --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > index 8de9d1535efb..c235b4357f7d 100644 > --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > @@ -4,7 +4,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > index 158f652cb3b1..e0e501deccfe 100644 > --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > @@ -7,5 +7,4 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > }; > diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > index f65f4067f3e9..5e46a2422d60 100644 > --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > @@ -4,7 +4,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > index a44ac35bdacd..1597473017ed 100644 > --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > index 62f572c4cf9f..64c43374c042 100644 > --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > @@ -14,7 +14,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > index ecba91aa30f5..1fc71faa9e07 100644 > --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > index caf524443079..74755a44eaee 100644 > --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > @@ -16,7 +16,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > index 46ebb77283f1..5b823fcca5fb 100644 > --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > @@ -20,7 +20,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > index e99e60185ebe..9ee9dd051e32 100644 > --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > @@ -31,7 +31,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > }; > > diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > index 471508a9ed74..ca2a684f3541 100644 > --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > }; > > diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > index 9a6a353088df..efba0c359ba5 100644 > --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > @@ -7,6 +7,5 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > };
On Mon, Feb 5, 2024 at 4:53 AM Jonas Karlman <jonas@kwiboo.se> wrote: > > Testing has shown that writing to eMMC using DDR52 mode does not seem to > work on RK356x and RK3588 boards. > > A simple test of writing a single block to e.g. sector 0x4000 fails: > > # Rescan using DDR52 mode > => mmc rescan 4 > > # Write a single block to sector 0x4000 fails with ERROR > => mmc write 20000000 4000 1 > > With the MMC_SPEED_MODE_SET Kconfig option enabled. > > Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected > board u-boot.dtsi files. > > Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Weizhao Ouyang <o451686892@gmail.com> BR, Weizhao > --- > Changes in v2: > - Update commit message > > Link to v1: https://patchwork.ozlabs.org/patch/1891695/ > --- > arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - > arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - > 12 files changed, 12 deletions(-) > > diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > index 11976fd3a6e0..930d660868bb 100644 > --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > index 8de9d1535efb..c235b4357f7d 100644 > --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi > @@ -4,7 +4,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > index 158f652cb3b1..e0e501deccfe 100644 > --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi > @@ -7,5 +7,4 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > }; > diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > index f65f4067f3e9..5e46a2422d60 100644 > --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi > @@ -4,7 +4,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > pinctrl-names = "default"; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > }; > diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > index a44ac35bdacd..1597473017ed 100644 > --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; > diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > index 62f572c4cf9f..64c43374c042 100644 > --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi > @@ -14,7 +14,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > index ecba91aa30f5..1fc71faa9e07 100644 > --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > index caf524443079..74755a44eaee 100644 > --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi > @@ -16,7 +16,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > index 46ebb77283f1..5b823fcca5fb 100644 > --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi > @@ -20,7 +20,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > mmc-hs400-1_8v; > mmc-hs400-enhanced-strobe; > diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > index e99e60185ebe..9ee9dd051e32 100644 > --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi > @@ -31,7 +31,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > }; > > diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > index 471508a9ed74..ca2a684f3541 100644 > --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > }; > > diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > index 9a6a353088df..efba0c359ba5 100644 > --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi > @@ -7,6 +7,5 @@ > > &sdhci { > cap-mmc-highspeed; > - mmc-ddr-1_8v; > mmc-hs200-1_8v; > }; > -- > 2.43.0 >
Hi Jonas, On 2/4/24 21:53, Jonas Karlman wrote: > Testing has shown that writing to eMMC using DDR52 mode does not seem to > work on RK356x and RK3588 boards. > > A simple test of writing a single block to e.g. sector 0x4000 fails: > > # Rescan using DDR52 mode > => mmc rescan 4 > > # Write a single block to sector 0x4000 fails with ERROR > => mmc write 20000000 4000 1 > > With the MMC_SPEED_MODE_SET Kconfig option enabled. > > Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected > board u-boot.dtsi files. > > Signed-off-by: Jonas Karlman <jonas@kwiboo.se> > --- > Changes in v2: > - Update commit message > > Link to v1: https://patchwork.ozlabs.org/patch/1891695/ > --- > arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - > arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - > arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - > arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - > arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - > 12 files changed, 12 deletions(-) > > diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > index 11976fd3a6e0..930d660868bb 100644 > --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi > @@ -8,7 +8,6 @@ > > &sdhci { > cap-mmc-highspeed; Shouldn't we also remove cap-mmc-highspeed? I assume this is for MMC_HS? Which we discovered doesn't work reliably? Since it could be in a different patch if you wanted to, for the changes in this patch: Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Thanks, Quentin
Hi Quentin, On 2024-02-05 10:40, Quentin Schulz wrote: > Hi Jonas, > > On 2/4/24 21:53, Jonas Karlman wrote: >> Testing has shown that writing to eMMC using DDR52 mode does not seem to >> work on RK356x and RK3588 boards. >> >> A simple test of writing a single block to e.g. sector 0x4000 fails: >> >> # Rescan using DDR52 mode >> => mmc rescan 4 >> >> # Write a single block to sector 0x4000 fails with ERROR >> => mmc write 20000000 4000 1 >> >> With the MMC_SPEED_MODE_SET Kconfig option enabled. >> >> Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected >> board u-boot.dtsi files. >> >> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> >> --- >> Changes in v2: >> - Update commit message >> >> Link to v1: https://patchwork.ozlabs.org/patch/1891695/ >> --- >> arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - >> arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - >> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - >> arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - >> 12 files changed, 12 deletions(-) >> >> diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >> index 11976fd3a6e0..930d660868bb 100644 >> --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >> +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >> @@ -8,7 +8,6 @@ >> >> &sdhci { >> cap-mmc-highspeed; > > Shouldn't we also remove cap-mmc-highspeed? > > I assume this is for MMC_HS? Which we discovered doesn't work reliably? Writing in lower speeds on RK356x does work better then on RK3588, however HS200 still seem to be more reliable overall and give more speed. For RK3588 they could possible be removed, but since reading does work and similar issue also existed in the fallback MMC legacy mode, I did not see that cleanup as important, or maybe more correctly it did not cross my mind to also remove these props :-), the fully broken ddr52 felt more important. > > Since it could be in a different patch if you wanted to, for the changes > in this patch: Agree, a possible cleanup of cap-mmc-highspeed props could be done in a separate patch. Alternatively any missing and appropriate modes currently in u-boot.dtsi should be added to linux DT and they can then be synced back to U-Boot and any override/addition dropped from u-boot.dtsi files. Regards, Jonas > > Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> > > Thanks, > Quentin
On 2024-02-05 14:24, Jonas Karlman wrote: > On 2024-02-05 10:40, Quentin Schulz wrote: >> On 2/4/24 21:53, Jonas Karlman wrote: >>> Testing has shown that writing to eMMC using DDR52 mode does not seem >>> to >>> work on RK356x and RK3588 boards. >>> >>> A simple test of writing a single block to e.g. sector 0x4000 fails: >>> >>> # Rescan using DDR52 mode >>> => mmc rescan 4 >>> >>> # Write a single block to sector 0x4000 fails with ERROR >>> => mmc write 20000000 4000 1 >>> >>> With the MMC_SPEED_MODE_SET Kconfig option enabled. >>> >>> Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in >>> affected >>> board u-boot.dtsi files. >>> >>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> >>> --- >>> Changes in v2: >>> - Update commit message >>> >>> Link to v1: https://patchwork.ozlabs.org/patch/1891695/ >>> --- >>> arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - >>> arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - >>> 12 files changed, 12 deletions(-) >>> >>> diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>> b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>> index 11976fd3a6e0..930d660868bb 100644 >>> --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>> +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>> @@ -8,7 +8,6 @@ >>> >>> &sdhci { >>> cap-mmc-highspeed; >> >> Shouldn't we also remove cap-mmc-highspeed? >> >> I assume this is for MMC_HS? Which we discovered doesn't work >> reliably? > > Writing in lower speeds on RK356x does work better then on RK3588, > however HS200 still seem to be more reliable overall and give more > speed. > > For RK3588 they could possible be removed, but since reading does work > and similar issue also existed in the fallback MMC legacy mode, I did > not see that cleanup as important, or maybe more correctly it did not > cross my mind to also remove these props :-), the fully broken ddr52 > felt more important. > >> >> Since it could be in a different patch if you wanted to, for the >> changes >> in this patch: > > Agree, a possible cleanup of cap-mmc-highspeed props could be done in a > separate patch. > > Alternatively any missing and appropriate modes currently in > u-boot.dtsi > should be added to linux DT and they can then be synced back to U-Boot > and any override/addition dropped from u-boot.dtsi files. How about waiting until I fix the mode selection in the Linux kernel drivers? As I noted already, that's already on my TODO list, and perhaps it would be good to test a bit again under Linux with those fixes applied, before actually removing the buggy modes from the kernel's RK356x and RK3588(s) SoC dtsi files. I expect to continue my work on those kernel bugfixes in the next few weeks. I did some work already, but left it there, and now I'll pick it up again.
Hi Dragan, On 2/5/24 14:40, Dragan Simic wrote: > [You don't often get email from dsimic@manjaro.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > On 2024-02-05 14:24, Jonas Karlman wrote: >> On 2024-02-05 10:40, Quentin Schulz wrote: >>> On 2/4/24 21:53, Jonas Karlman wrote: >>>> Testing has shown that writing to eMMC using DDR52 mode does not seem >>>> to >>>> work on RK356x and RK3588 boards. >>>> >>>> A simple test of writing a single block to e.g. sector 0x4000 fails: >>>> >>>> # Rescan using DDR52 mode >>>> => mmc rescan 4 >>>> >>>> # Write a single block to sector 0x4000 fails with ERROR >>>> => mmc write 20000000 4000 1 >>>> >>>> With the MMC_SPEED_MODE_SET Kconfig option enabled. >>>> >>>> Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in >>>> affected >>>> board u-boot.dtsi files. >>>> >>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> >>>> --- >>>> Changes in v2: >>>> - Update commit message >>>> >>>> Link to v1: >>>> https://patchwork.ozlabs.org/patch/1891695/ >>>> --- >>>> arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - >>>> arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - >>>> 12 files changed, 12 deletions(-) >>>> >>>> diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>>> b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>>> index 11976fd3a6e0..930d660868bb 100644 >>>> --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>>> +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi >>>> @@ -8,7 +8,6 @@ >>>> >>>> &sdhci { >>>> cap-mmc-highspeed; >>> >>> Shouldn't we also remove cap-mmc-highspeed? >>> >>> I assume this is for MMC_HS? Which we discovered doesn't work >>> reliably? >> >> Writing in lower speeds on RK356x does work better then on RK3588, >> however HS200 still seem to be more reliable overall and give more >> speed. >> >> For RK3588 they could possible be removed, but since reading does work >> and similar issue also existed in the fallback MMC legacy mode, I did >> not see that cleanup as important, or maybe more correctly it did not >> cross my mind to also remove these props :-), the fully broken ddr52 >> felt more important. >> >>> >>> Since it could be in a different patch if you wanted to, for the >>> changes >>> in this patch: >> >> Agree, a possible cleanup of cap-mmc-highspeed props could be done in a >> separate patch. >> >> Alternatively any missing and appropriate modes currently in >> u-boot.dtsi >> should be added to linux DT and they can then be synced back to U-Boot >> and any override/addition dropped from u-boot.dtsi files. > > How about waiting until I fix the mode selection in the Linux kernel > drivers? As I noted already, that's already on my TODO list, and > perhaps it would be good to test a bit again under Linux with those > fixes applied, before actually removing the buggy modes from the > kernel's RK356x and RK3588(s) SoC dtsi files. > While I appreciate there's some work that can be done in the Linux kernel for those low-speed modes, the properties in question are removed only from U-Boot's DTS and your future patches for the kernel wouldn't impact the bootloader anyway. The issue right now is that U-Boot is currently broken because of those properties, which are only in U-Boot's DTS. Not sure exactly why we should waiting on Linux kernel patches for merging work-arounds for U-Boot? What exactly are you suggesting we wait for? What can improve the situation? Cheers, Quentin
On 2024-02-05 14:45, Quentin Schulz wrote: > On 2/5/24 14:40, Dragan Simic wrote: >> On 2024-02-05 14:24, Jonas Karlman wrote: >>> On 2024-02-05 10:40, Quentin Schulz wrote: >>>> Shouldn't we also remove cap-mmc-highspeed? >>>> >>>> I assume this is for MMC_HS? Which we discovered doesn't work >>>> reliably? >>> >>> Writing in lower speeds on RK356x does work better then on RK3588, >>> however HS200 still seem to be more reliable overall and give more >>> speed. >>> >>> For RK3588 they could possible be removed, but since reading does >>> work >>> and similar issue also existed in the fallback MMC legacy mode, I did >>> not see that cleanup as important, or maybe more correctly it did not >>> cross my mind to also remove these props :-), the fully broken ddr52 >>> felt more important. >>> >>>> Since it could be in a different patch if you wanted to, for the >>>> changes in this patch: >>> >>> Agree, a possible cleanup of cap-mmc-highspeed props could be done in >>> a >>> separate patch. >>> >>> Alternatively any missing and appropriate modes currently in >>> u-boot.dtsi >>> should be added to linux DT and they can then be synced back to >>> U-Boot >>> and any override/addition dropped from u-boot.dtsi files. >> >> How about waiting until I fix the mode selection in the Linux kernel >> drivers? As I noted already, that's already on my TODO list, and >> perhaps it would be good to test a bit again under Linux with those >> fixes applied, before actually removing the buggy modes from the >> kernel's RK356x and RK3588(s) SoC dtsi files. > > While I appreciate there's some work that can be done in the Linux > kernel for those low-speed modes, the properties in question are > removed only from U-Boot's DTS and your future patches for the kernel > wouldn't impact the bootloader anyway. > > The issue right now is that U-Boot is currently broken because of > those properties, which are only in U-Boot's DTS. > > Not sure exactly why we should waiting on Linux kernel patches for > merging work-arounds for U-Boot? What exactly are you suggesting we > wait for? What can improve the situation? Ah, sorry for the confusion, let me clarify a bit... I just replied to the Jonas's remark about the need to eventually have the same fixes and mode removals in the Linux kernel's SoC dtsi files. In other words, all I wrote was about those changes, not about the changes on the U-Boot side. Of course, there are no reasons for delaying these U-Boot fixes.
On 2024-02-05 14:51, Dragan Simic wrote: > On 2024-02-05 14:45, Quentin Schulz wrote: >> On 2/5/24 14:40, Dragan Simic wrote: >>> On 2024-02-05 14:24, Jonas Karlman wrote: >>>> On 2024-02-05 10:40, Quentin Schulz wrote: >>>>> Shouldn't we also remove cap-mmc-highspeed? >>>>> >>>>> I assume this is for MMC_HS? Which we discovered doesn't work >>>>> reliably? >>>> >>>> Writing in lower speeds on RK356x does work better then on RK3588, >>>> however HS200 still seem to be more reliable overall and give more >>>> speed. >>>> >>>> For RK3588 they could possible be removed, but since reading does >>>> work >>>> and similar issue also existed in the fallback MMC legacy mode, I did >>>> not see that cleanup as important, or maybe more correctly it did not >>>> cross my mind to also remove these props :-), the fully broken ddr52 >>>> felt more important. >>>> >>>>> Since it could be in a different patch if you wanted to, for the >>>>> changes in this patch: >>>> >>>> Agree, a possible cleanup of cap-mmc-highspeed props could be done in >>>> a >>>> separate patch. >>>> >>>> Alternatively any missing and appropriate modes currently in >>>> u-boot.dtsi >>>> should be added to linux DT and they can then be synced back to >>>> U-Boot >>>> and any override/addition dropped from u-boot.dtsi files. >>> >>> How about waiting until I fix the mode selection in the Linux kernel >>> drivers? As I noted already, that's already on my TODO list, and >>> perhaps it would be good to test a bit again under Linux with those >>> fixes applied, before actually removing the buggy modes from the >>> kernel's RK356x and RK3588(s) SoC dtsi files. >> >> While I appreciate there's some work that can be done in the Linux >> kernel for those low-speed modes, the properties in question are >> removed only from U-Boot's DTS and your future patches for the kernel >> wouldn't impact the bootloader anyway. >> >> The issue right now is that U-Boot is currently broken because of >> those properties, which are only in U-Boot's DTS. >> >> Not sure exactly why we should waiting on Linux kernel patches for >> merging work-arounds for U-Boot? What exactly are you suggesting we >> wait for? What can improve the situation? > > Ah, sorry for the confusion, let me clarify a bit... > > I just replied to the Jonas's remark about the need to eventually > have the same fixes and mode removals in the Linux kernel's SoC dtsi > files. In other words, all I wrote was about those changes, not > about the changes on the U-Boot side. > > Of course, there are no reasons for delaying these U-Boot fixes. Short history about the added eMMC modes in u-boot.dtsi on RK35xx boards: U-Boot defaults to not support HS200+ modes unless explicitly enabled in Kconfig options and on top of that the driver require DT to have a corresponding mode prop to make use of any mode faster than MMC legacy. When I worked on eMMC fixes for RK3568 and support for RK3588 [1] I only tested reading data using all modes. Because reading data in all modes seem to work on the boards I tested on, I eventually added the "missing" props to board u-boot.dtsi-files, so that U-Boot could make use of faster modes. However, I opted to only enable the HS200 Kconfig option on boards with embedded eMMC. This has resulted in that most RK35xx boards now default to using the fastest none HS200+ mode, i.e. DDR52 mode. They would also try to use a faster mode as long as a HS200+ Kconfig option is enabled. With the removal of mmc-ddr-1_8v prop in this series, at least the most broken mode is avoided for all RK35xx boards. And with the HS200 Kconfig option enabled by default, the required tuning in HS200+ mode should automatically happen as long as eMMC module support HS200 mode. After that writing in any supported lower speed seem to work OK. In the case where HS200 is supported any read/write in lower speed seem to work, so the modes provided by cap-mmc-highspeed prop is OK. However, if HS200+ is not supported it does not really matter, first write will fail in any remaining mode, the slowest legacy or the modes provided by cap-mmc-highspeed prop. Keeping the cap-mmc-highspeed prop at least make reading data faster possible, and writing data is still semi-broken in any remaining mode. In conclusion I suggest: - We keep the cap-mmc-highspeed props in board u-boot.dtsi for now. - The mmc mode props that has been added in board u-boot.dtsi and have been validated working with both U-Boot and linux should be added to board DT. e.g HS200+ props is missing in some board DT. - When an updated board DT has been synced from linux, any override in board u-boot.dtsi should be dropped. I am also fine with completely dropping cap-mmc-highspeed props now if they cause issues not solved by the HS200 Kconfig option being enabled. [1] https://patchwork.ozlabs.org/cover/1764606/ Regards, Jonas
Hello Jonas, On 2024-02-05 18:01, Jonas Karlman wrote: > On 2024-02-05 14:51, Dragan Simic wrote: >> On 2024-02-05 14:45, Quentin Schulz wrote: >>> On 2/5/24 14:40, Dragan Simic wrote: >>>> How about waiting until I fix the mode selection in the Linux kernel >>>> drivers? As I noted already, that's already on my TODO list, and >>>> perhaps it would be good to test a bit again under Linux with those >>>> fixes applied, before actually removing the buggy modes from the >>>> kernel's RK356x and RK3588(s) SoC dtsi files. >>> >>> While I appreciate there's some work that can be done in the Linux >>> kernel for those low-speed modes, the properties in question are >>> removed only from U-Boot's DTS and your future patches for the kernel >>> wouldn't impact the bootloader anyway. >>> >>> The issue right now is that U-Boot is currently broken because of >>> those properties, which are only in U-Boot's DTS. >>> >>> Not sure exactly why we should waiting on Linux kernel patches for >>> merging work-arounds for U-Boot? What exactly are you suggesting we >>> wait for? What can improve the situation? >> >> Ah, sorry for the confusion, let me clarify a bit... >> >> I just replied to the Jonas's remark about the need to eventually >> have the same fixes and mode removals in the Linux kernel's SoC dtsi >> files. In other words, all I wrote was about those changes, not >> about the changes on the U-Boot side. >> >> Of course, there are no reasons for delaying these U-Boot fixes. > > Short history about the added eMMC modes in u-boot.dtsi on RK35xx > boards: > > U-Boot defaults to not support HS200+ modes unless explicitly enabled > in > Kconfig options and on top of that the driver require DT to have a > corresponding mode prop to make use of any mode faster than MMC legacy. > > When I worked on eMMC fixes for RK3568 and support for RK3588 [1] I > only > tested reading data using all modes. > > Because reading data in all modes seem to work on the boards I tested > on, > I eventually added the "missing" props to board u-boot.dtsi-files, so > that U-Boot could make use of faster modes. However, I opted to only > enable the HS200 Kconfig option on boards with embedded eMMC. > > This has resulted in that most RK35xx boards now default to using the > fastest none HS200+ mode, i.e. DDR52 mode. They would also try to use a > faster mode as long as a HS200+ Kconfig option is enabled. > > With the removal of mmc-ddr-1_8v prop in this series, at least the most > broken mode is avoided for all RK35xx boards. And with the HS200 > Kconfig > option enabled by default, the required tuning in HS200+ mode should > automatically happen as long as eMMC module support HS200 mode. After > that writing in any supported lower speed seem to work OK. > > In the case where HS200 is supported any read/write in lower speed seem > to work, so the modes provided by cap-mmc-highspeed prop is OK. > > However, if HS200+ is not supported it does not really matter, first > write will fail in any remaining mode, the slowest legacy or the modes > provided by cap-mmc-highspeed prop. > > Keeping the cap-mmc-highspeed prop at least make reading data faster > possible, and writing data is still semi-broken in any remaining mode. > > In conclusion I suggest: > > - We keep the cap-mmc-highspeed props in board u-boot.dtsi for now. > > - The mmc mode props that has been added in board u-boot.dtsi and have > been validated working with both U-Boot and linux should be added to > board DT. e.g HS200+ props is missing in some board DT. > > - When an updated board DT has been synced from linux, any override in > board u-boot.dtsi should be dropped. > > I am also fine with completely dropping cap-mmc-highspeed props now if > they cause issues not solved by the HS200 Kconfig option being enabled. > > [1] https://patchwork.ozlabs.org/cover/1764606/ Thank you for taking the time to write this detailed summary! It's somewhat unexpected that the writes to eMMC fail to work while the reads work fine. As we know, the writes don't introduce the delay between the host-generated clock and the data to be written. It would be expected for the reads to be more error-prone.
diff --git a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi index 11976fd3a6e0..930d660868bb 100644 --- a/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi @@ -8,7 +8,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi index 8de9d1535efb..c235b4357f7d 100644 --- a/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi +++ b/arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi @@ -4,7 +4,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi index 158f652cb3b1..e0e501deccfe 100644 --- a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi +++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi @@ -7,5 +7,4 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; }; diff --git a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi index f65f4067f3e9..5e46a2422d60 100644 --- a/arch/arm/dts/rk3566-soquartz-u-boot.dtsi +++ b/arch/arm/dts/rk3566-soquartz-u-boot.dtsi @@ -4,7 +4,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; }; diff --git a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi index a44ac35bdacd..1597473017ed 100644 --- a/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi +++ b/arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi @@ -8,7 +8,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi index 62f572c4cf9f..64c43374c042 100644 --- a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi @@ -14,7 +14,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi index ecba91aa30f5..1fc71faa9e07 100644 --- a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi @@ -8,7 +8,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi index caf524443079..74755a44eaee 100644 --- a/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi +++ b/arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi @@ -16,7 +16,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi index 46ebb77283f1..5b823fcca5fb 100644 --- a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi @@ -20,7 +20,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi index e99e60185ebe..9ee9dd051e32 100644 --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi @@ -31,7 +31,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; }; diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi index 471508a9ed74..ca2a684f3541 100644 --- a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi +++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi @@ -8,7 +8,6 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; }; diff --git a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi index 9a6a353088df..efba0c359ba5 100644 --- a/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi +++ b/arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi @@ -7,6 +7,5 @@ &sdhci { cap-mmc-highspeed; - mmc-ddr-1_8v; mmc-hs200-1_8v; };
Testing has shown that writing to eMMC using DDR52 mode does not seem to work on RK356x and RK3588 boards. A simple test of writing a single block to e.g. sector 0x4000 fails: # Rescan using DDR52 mode => mmc rescan 4 # Write a single block to sector 0x4000 fails with ERROR => mmc write 20000000 4000 1 With the MMC_SPEED_MODE_SET Kconfig option enabled. Fix this by removing the mmc-ddr-1_8v prop from sdhci nodes in affected board u-boot.dtsi files. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> --- Changes in v2: - Update commit message Link to v1: https://patchwork.ozlabs.org/patch/1891695/ --- arch/arm/dts/rk3566-quartz64-a-u-boot.dtsi | 1 - arch/arm/dts/rk3566-quartz64-b-u-boot.dtsi | 1 - arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 1 - arch/arm/dts/rk3566-soquartz-u-boot.dtsi | 1 - arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 1 - arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 1 - arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 1 - arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 1 - arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 1 - arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 1 - arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi | 1 - arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 1 - 12 files changed, 12 deletions(-)