[PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>

Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
corruption when using HS400 mode. Downgrade to HS200 mode to ensure
stable operation.

Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
index fafeabe9adf9..5f63f38f7326 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
@@ -717,8 +717,7 @@ &sdhci {
 	no-sd;
 	non-removable;
 	max-frequency = <200000000>;
-	mmc-hs400-1_8v;
-	mmc-hs400-enhanced-strobe;
+	mmc-hs200-1_8v;
 	status = "okay";
 };
 
-- 
2.51.0

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Tianling,

On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> 
> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> stable operation.

Could you, please, provide more details about the troublesome eMMC
chip that gets identified as A3A444, i.e. what's the actual brand
and model?  Maybe you could send a picture of it?  It might also
help if you'd send the contents of "/sys/class/block/mmcblkX/device
/manfid" from your board (where "X" should equal two).

I'm asking for that because I'd like to research it a bit further,
if possible, because some other eMMC chips that are also found on
the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
the A3A444 chip has some issues with the HS400 mode on its own,
i.e. the observed issues may not be caused by the board.

[1] https://github.com/openwrt/openwrt/issues/18844

> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> index fafeabe9adf9..5f63f38f7326 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> @@ -717,8 +717,7 @@ &sdhci {
>  	no-sd;
>  	non-removable;
>  	max-frequency = <200000000>;
> -	mmc-hs400-1_8v;
> -	mmc-hs400-enhanced-strobe;
> +	mmc-hs200-1_8v;
>  	status = "okay";
>  };

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

Hi Dragan,

On 2025/10/17 18:25, Dragan Simic wrote:
> Hello Tianling,
> 
> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>
>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>> stable operation.
> 
> Could you, please, provide more details about the troublesome eMMC
> chip that gets identified as A3A444, i.e. what's the actual brand
> and model?  Maybe you could send a picture of it?  It might also
> help if you'd send the contents of "/sys/class/block/mmcblkX/device
> /manfid" from your board (where "X" should equal two).

Unfortunately I don't have this board nor this eMMC chip.
I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44, 
manfid is 0x0000d6.

> 
> I'm asking for that because I'd like to research it a bit further,
> if possible, because some other eMMC chips that are also found on
> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> the A3A444 chip has some issues with the HS400 mode on its own,
> i.e. the observed issues may not be caused by the board.

Yes, it should be caused by this eMMC chip.

Thanks,
Tianling.

> 
> [1] https://github.com/openwrt/openwrt/issues/18844
> 
>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> index fafeabe9adf9..5f63f38f7326 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> @@ -717,8 +717,7 @@ &sdhci {
>>   	no-sd;
>>   	non-removable;
>>   	max-frequency = <200000000>;
>> -	mmc-hs400-1_8v;
>> -	mmc-hs400-enhanced-strobe;
>> +	mmc-hs200-1_8v;
>>   	status = "okay";
>>   };
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> On 2025/10/17 18:25, Dragan Simic wrote:
> > On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> >> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>
> >> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> >> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> >> stable operation.
> > 
> > Could you, please, provide more details about the troublesome eMMC
> > chip that gets identified as A3A444, i.e. what's the actual brand
> > and model?  Maybe you could send a picture of it?  It might also
> > help if you'd send the contents of "/sys/class/block/mmcblkX/device
> > /manfid" from your board (where "X" should equal two).
> 
> Unfortunately I don't have this board nor this eMMC chip.
> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44, 
> manfid is 0x0000d6.

Thanks for responding and providing the details so quickly!

> > I'm asking for that because I'd like to research it a bit further,
> > if possible, because some other eMMC chips that are also found on
> > the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> > the A3A444 chip has some issues with the HS400 mode on its own,
> > i.e. the observed issues may not be caused by the board.
> 
> Yes, it should be caused by this eMMC chip.

I'd suggest that we move forward by "quirking off" the HS400 mode
for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
downgrading the speed of the sdhci interface on the NanoPC-T6.

That way, the other similar Foresee eMMC chip that's also found
on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
the faster HS400 mode, while the troublesome A3A44 variant will
be downgraded to the HS200 globally for everyone's benefit.  It's
quite unlikely that the A3A44 variant fails to work reliable in
HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
drivers should be a sane and safe choice.

If you agree with dropping this patch, I'll be more than happy
to implement this HS200 quirk in the MMC drivers.

As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
eMMC Support List v1.84, [2] but the evidence says the opposite,
so we should react appropriately by adding this quirk.

[1] https://github.com/openwrt/openwrt/issues/18844
[2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf

> >> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> >> ---
> >>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> >>   1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >> index fafeabe9adf9..5f63f38f7326 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >> @@ -717,8 +717,7 @@ &sdhci {
> >>   	no-sd;
> >>   	non-removable;
> >>   	max-frequency = <200000000>;
> >> -	mmc-hs400-1_8v;
> >> -	mmc-hs400-enhanced-strobe;
> >> +	mmc-hs200-1_8v;
> >>   	status = "okay";
> >>   };

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

On 2025/10/17 23:15, Dragan Simic wrote:
> On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
>> On 2025/10/17 18:25, Dragan Simic wrote:
>>> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
>>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>>
>>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>>>> stable operation.
>>>
>>> Could you, please, provide more details about the troublesome eMMC
>>> chip that gets identified as A3A444, i.e. what's the actual brand
>>> and model?  Maybe you could send a picture of it?  It might also
>>> help if you'd send the contents of "/sys/class/block/mmcblkX/device
>>> /manfid" from your board (where "X" should equal two).
>>
>> Unfortunately I don't have this board nor this eMMC chip.
>> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
>> manfid is 0x0000d6.
> 
> Thanks for responding and providing the details so quickly!
> 
>>> I'm asking for that because I'd like to research it a bit further,
>>> if possible, because some other eMMC chips that are also found on
>>> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
>>> the A3A444 chip has some issues with the HS400 mode on its own,
>>> i.e. the observed issues may not be caused by the board.
>>
>> Yes, it should be caused by this eMMC chip.
> 
> I'd suggest that we move forward by "quirking off" the HS400 mode
> for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> downgrading the speed of the sdhci interface on the NanoPC-T6.
> 
> That way, the other similar Foresee eMMC chip that's also found
> on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> the faster HS400 mode, while the troublesome A3A44 variant will
> be downgraded to the HS200 globally for everyone's benefit.  It's
> quite unlikely that the A3A44 variant fails to work reliable in
> HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> drivers should be a sane and safe choice.
> 
> If you agree with dropping this patch, I'll be more than happy
> to implement this HS200 quirk in the MMC drivers.

Yes for sure, thank you ;)
The full cid is d6010341334134343411f63ea7208700.

Thanks,
Tianling.

> 
> As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> eMMC Support List v1.84, [2] but the evidence says the opposite,
> so we should react appropriately by adding this quirk.
> 
> [1] https://github.com/openwrt/openwrt/issues/18844
> [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
> 
>>>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>>>> ---
>>>>    arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>> index fafeabe9adf9..5f63f38f7326 100644
>>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>> @@ -717,8 +717,7 @@ &sdhci {
>>>>    	no-sd;
>>>>    	non-removable;
>>>>    	max-frequency = <200000000>;
>>>> -	mmc-hs400-1_8v;
>>>> -	mmc-hs400-enhanced-strobe;
>>>> +	mmc-hs200-1_8v;
>>>>    	status = "okay";
>>>>    };
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

On Friday, October 17, 2025 18:34 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> On 2025/10/17 23:15, Dragan Simic wrote:
> > On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> >> On 2025/10/17 18:25, Dragan Simic wrote:
> >>> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> >>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>>>
> >>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> >>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> >>>> stable operation.
> >>>
> >>> Could you, please, provide more details about the troublesome eMMC
> >>> chip that gets identified as A3A444, i.e. what's the actual brand
> >>> and model?  Maybe you could send a picture of it?  It might also
> >>> help if you'd send the contents of "/sys/class/block/mmcblkX/device
> >>> /manfid" from your board (where "X" should equal two).
> >>
> >> Unfortunately I don't have this board nor this eMMC chip.
> >> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
> >> manfid is 0x0000d6.
> > 
> > Thanks for responding and providing the details so quickly!
> > 
> >>> I'm asking for that because I'd like to research it a bit further,
> >>> if possible, because some other eMMC chips that are also found on
> >>> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> >>> the A3A444 chip has some issues with the HS400 mode on its own,
> >>> i.e. the observed issues may not be caused by the board.
> >>
> >> Yes, it should be caused by this eMMC chip.
> > 
> > I'd suggest that we move forward by "quirking off" the HS400 mode
> > for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> > downgrading the speed of the sdhci interface on the NanoPC-T6.
> > 
> > That way, the other similar Foresee eMMC chip that's also found
> > on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> > the faster HS400 mode, while the troublesome A3A44 variant will
> > be downgraded to the HS200 globally for everyone's benefit.  It's
> > quite unlikely that the A3A44 variant fails to work reliable in
> > HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> > drivers should be a sane and safe choice.
> > 
> > If you agree with dropping this patch, I'll be more than happy
> > to implement this HS200 quirk in the MMC drivers.
> 
> Yes for sure, thank you ;)
> The full cid is d6010341334134343411f63ea7208700.

Great, thanks!  I'll start working on the proposed MMC quirk patch
tomorrow or so, and I'll feel free to ask for some more observable
A3A44 chip variant data, if needed.

> > As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> > eMMC Support List v1.84, [2] but the evidence says the opposite,
> > so we should react appropriately by adding this quirk.
> > 
> > [1] https://github.com/openwrt/openwrt/issues/18844
> > [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
> > 
> >>>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> >>>> ---
> >>>>    arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> >>>>    1 file changed, 1 insertion(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>>> index fafeabe9adf9..5f63f38f7326 100644
> >>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>>> @@ -717,8 +717,7 @@ &sdhci {
> >>>>    	no-sd;
> >>>>    	non-removable;
> >>>>    	max-frequency = <200000000>;
> >>>> -	mmc-hs400-1_8v;
> >>>> -	mmc-hs400-enhanced-strobe;
> >>>> +	mmc-hs200-1_8v;
> >>>>    	status = "okay";
> >>>>    };

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Jimmy Hon]

On Fri, Oct 17, 2025 at 10:15 AM Dragan Simic <dsimic@manjaro.org> wrote:
>
> On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > On 2025/10/17 18:25, Dragan Simic wrote:
> > > On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > >> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > >>
> > >> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > >> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > >> stable operation.
> > >
> > > Could you, please, provide more details about the troublesome eMMC
> > > chip that gets identified as A3A444, i.e. what's the actual brand
> > > and model?  Maybe you could send a picture of it?  It might also
> > > help if you'd send the contents of "/sys/class/block/mmcblkX/device
> > > /manfid" from your board (where "X" should equal two).
> >
> > Unfortunately I don't have this board nor this eMMC chip.
> > I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
> > manfid is 0x0000d6.
>
> Thanks for responding and providing the details so quickly!
>
> > > I'm asking for that because I'd like to research it a bit further,
> > > if possible, because some other eMMC chips that are also found on
> > > the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> > > the A3A444 chip has some issues with the HS400 mode on its own,
> > > i.e. the observed issues may not be caused by the board.
> >
> > Yes, it should be caused by this eMMC chip.
>
> I'd suggest that we move forward by "quirking off" the HS400 mode
> for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> downgrading the speed of the sdhci interface on the NanoPC-T6.
>
> That way, the other similar Foresee eMMC chip that's also found
> on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> the faster HS400 mode, while the troublesome A3A44 variant will
> be downgraded to the HS200 globally for everyone's benefit.  It's
> quite unlikely that the A3A44 variant fails to work reliable in
> HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> drivers should be a sane and safe choice.
>
> If you agree with dropping this patch, I'll be more than happy
> to implement this HS200 quirk in the MMC drivers.
>
> As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> eMMC Support List v1.84, [2] but the evidence says the opposite,
> so we should react appropriately by adding this quirk.

When adding the quirk for the A3A44, can we lower the max frequency
and keep the HS400 mode instead?
That's what the Fedora folks found works [1]. There's more test
results in Armbian [2]

[1] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/MCSDYDQVOXS5AZMKA7LLY4QX7JXBWPCA/
[2] https://github.com/armbian/build/pull/8736#issuecomment-3387760536

>
> [1] https://github.com/openwrt/openwrt/issues/18844
> [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Jimmy,

On Saturday, October 18, 2025 02:42 CEST, Jimmy Hon <honyuenkwun@gmail.com> wrote:
> On Fri, Oct 17, 2025 at 10:15 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > > On 2025/10/17 18:25, Dragan Simic wrote:
> > > > On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > > >> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > > >>
> > > >> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > > >> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > > >> stable operation.
> > > >
> > > > Could you, please, provide more details about the troublesome eMMC
> > > > chip that gets identified as A3A444, i.e. what's the actual brand
> > > > and model?  Maybe you could send a picture of it?  It might also
> > > > help if you'd send the contents of "/sys/class/block/mmcblkX/device
> > > > /manfid" from your board (where "X" should equal two).
> > >
> > > Unfortunately I don't have this board nor this eMMC chip.
> > > I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
> > > manfid is 0x0000d6.
> >
> > Thanks for responding and providing the details so quickly!
> >
> > > > I'm asking for that because I'd like to research it a bit further,
> > > > if possible, because some other eMMC chips that are also found on
> > > > the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> > > > the A3A444 chip has some issues with the HS400 mode on its own,
> > > > i.e. the observed issues may not be caused by the board.
> > >
> > > Yes, it should be caused by this eMMC chip.
> >
> > I'd suggest that we move forward by "quirking off" the HS400 mode
> > for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> > downgrading the speed of the sdhci interface on the NanoPC-T6.
> >
> > That way, the other similar Foresee eMMC chip that's also found
> > on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> > the faster HS400 mode, while the troublesome A3A44 variant will
> > be downgraded to the HS200 globally for everyone's benefit.  It's
> > quite unlikely that the A3A44 variant fails to work reliable in
> > HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> > drivers should be a sane and safe choice.
> >
> > If you agree with dropping this patch, I'll be more than happy
> > to implement this HS200 quirk in the MMC drivers.
> >
> > As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> > eMMC Support List v1.84, [2] but the evidence says the opposite,
> > so we should react appropriately by adding this quirk.
> 
> When adding the quirk for the A3A44, can we lower the max frequency
> and keep the HS400 mode instead?
> That's what the Fedora folks found works [3]. There's more test
> results in Armbian [4]

Are there any I/O performance tests that would prove that lowering
the HS400 frequency to 150 MHz ends up working significantly faster
than dropping the eMMC chip to HS200 mode?

I'm asking that because lowering the frequency looks much more like
there's some issue with the board, rather than the issue being the
eMMC chip's support for HS400 mode.  Thus, a quirk that would lower
the HS400 mode frequency would likely be frowned upon and rejected,
while a quirk that puts the chip into HS200 mode is much cleaner
and has much higher chances to be accepted.

With all that in mind, if the resulting I/O performance difference
between 150 MHz HS400 and HS200 is within 15-20% or so, I'd highly
recommend that we still go with the HS200 quirk.  It also leaves
us with a nice safety margin, which is always good to have when
such hardware instability issues are worked around in software,
unless detailed eye diagrams, protocol dumps and whatnot can be
pulled and analyzed, in which case the resulting safety margin
can be much slimmer.

Ideally, we'd have a completely different board with the same
Foresee FEMDNN256G-A3A44 eMMC chip to test how reliably its HS400
mode works there, to see is it really up to this eMMC chip or up
to the board design, but I'm afraid we don't have that (easily)
available, so the only remaining option is to work with what's
actually available, which inevitably leads to a certain amount
of guesswork and some compromises.

> > [1] https://github.com/openwrt/openwrt/issues/18844
> > [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
> [3] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/MCSDYDQVOXS5AZMKA7LLY4QX7JXBWPCA/
> [4] https://github.com/armbian/build/pull/8736#issuecomment-3387760536

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Hugh Cole-Baker]

Hi Dragan,

On 18/10/2025 09:30, Dragan Simic wrote:
> Hello Jimmy,
> 
> On Saturday, October 18, 2025 02:42 CEST, Jimmy Hon <honyuenkwun@gmail.com> wrote:
>> On Fri, Oct 17, 2025 at 10:15 AM Dragan Simic <dsimic@manjaro.org> wrote:
>>> On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
>>>> On 2025/10/17 18:25, Dragan Simic wrote:
>>>>> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
>>>>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>>>>
>>>>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>>>>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>>>>>> stable operation.
>>>>>
>>>>> Could you, please, provide more details about the troublesome eMMC
>>>>> chip that gets identified as A3A444, i.e. what's the actual brand
>>>>> and model?  Maybe you could send a picture of it?  It might also
>>>>> help if you'd send the contents of "/sys/class/block/mmcblkX/device
>>>>> /manfid" from your board (where "X" should equal two).
>>>>
>>>> Unfortunately I don't have this board nor this eMMC chip.
>>>> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
>>>> manfid is 0x0000d6.
>>>
>>> Thanks for responding and providing the details so quickly!
>>>
>>>>> I'm asking for that because I'd like to research it a bit further,
>>>>> if possible, because some other eMMC chips that are also found on
>>>>> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
>>>>> the A3A444 chip has some issues with the HS400 mode on its own,
>>>>> i.e. the observed issues may not be caused by the board.
>>>>
>>>> Yes, it should be caused by this eMMC chip.
>>>
>>> I'd suggest that we move forward by "quirking off" the HS400 mode
>>> for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
>>> downgrading the speed of the sdhci interface on the NanoPC-T6.
>>>
>>> That way, the other similar Foresee eMMC chip that's also found
>>> on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
>>> the faster HS400 mode, while the troublesome A3A44 variant will
>>> be downgraded to the HS200 globally for everyone's benefit.  It's
>>> quite unlikely that the A3A44 variant fails to work reliable in
>>> HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
>>> drivers should be a sane and safe choice.
>>>
>>> If you agree with dropping this patch, I'll be more than happy
>>> to implement this HS200 quirk in the MMC drivers.
>>>
>>> As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
>>> eMMC Support List v1.84, [2] but the evidence says the opposite,
>>> so we should react appropriately by adding this quirk.
>>
>> When adding the quirk for the A3A44, can we lower the max frequency
>> and keep the HS400 mode instead?
>> That's what the Fedora folks found works [3]. There's more test
>> results in Armbian [4]
> 
> Are there any I/O performance tests that would prove that lowering
> the HS400 frequency to 150 MHz ends up working significantly faster
> than dropping the eMMC chip to HS200 mode?
> 
> I'm asking that because lowering the frequency looks much more like
> there's some issue with the board, rather than the issue being the
> eMMC chip's support for HS400 mode.  Thus, a quirk that would lower
> the HS400 mode frequency would likely be frowned upon and rejected,
> while a quirk that puts the chip into HS200 mode is much cleaner
> and has much higher chances to be accepted.

I also have the NanoPC-T6 with one of the A3A444 eMMCs which suffers
from I/O errors in the default HS400 mode. These are its details in
/sys/block/mmcblk0/device/:
manfid: 0x0000d6
oemid: 0x0103
name: A3A444
fwrev: 0x1100000000000000
hwrev: 0x0
rev: 0x8

I wasn't sure if I was just unlucky to get a faulty chip, but seeing
this thread it seems like a wider issue. On my board, limiting it to
HS200 mode gets rid of the I/O errors, and it seems that lowering
the frequency to 150MHz also avoids I/O errors.

I did a quick unscientific test with fio; HS400 Enhanced Strobe mode
with a 150MHz clock gives slightly better performance than HS200:

HS200 mode:
read: IOPS=697, BW=43.6MiB/s
write: IOPS=697, BW=43.6MiB/s

HS400 mode with 150MHz clock:
read: IOPS=805, BW=50.3MiB/s
write: IOPS=799, BW=50.0MiB/s

so from my perspective, limiting the frequency would be a better fix
than disabling HS400 entirely.

It could also be of interest that the clock used apparently can't
provide an exact 200MHz, e.g. in HS200 mode:

root@t6:~# cat /sys/kernel/debug/mmc0/ios
clock:		200000000 Hz
actual clock:	187500000 Hz
vdd:		18 (3.0 ~ 3.1 V)
bus mode:	2 (push-pull)
chip select:	0 (don't care)
power mode:	2 (on)
bus width:	3 (8 bits)
timing spec:	9 (mmc HS200)
signal voltage:	1 (1.80 V)
driver type:	0 (driver type B)

> With all that in mind, if the resulting I/O performance difference
> between 150 MHz HS400 and HS200 is within 15-20% or so, I'd highly
> recommend that we still go with the HS200 quirk.  It also leaves
> us with a nice safety margin, which is always good to have when
> such hardware instability issues are worked around in software,
> unless detailed eye diagrams, protocol dumps and whatnot can be
> pulled and analyzed, in which case the resulting safety margin
> can be much slimmer.
> 
> Ideally, we'd have a completely different board with the same
> Foresee FEMDNN256G-A3A44 eMMC chip to test how reliably its HS400
> mode works there, to see is it really up to this eMMC chip or up
> to the board design, but I'm afraid we don't have that (easily)
> available, so the only remaining option is to work with what's
> actually available, which inevitably leads to a certain amount
> of guesswork and some compromises.
> 
>>> [1] https://github.com/openwrt/openwrt/issues/18844
>>> [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
>> [3] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/MCSDYDQVOXS5AZMKA7LLY4QX7JXBWPCA/
>> [4] https://github.com/armbian/build/pull/8736#issuecomment-3387760536

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Hugh,

On Saturday, October 18, 2025 14:14 CEST, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> On 18/10/2025 09:30, Dragan Simic wrote:
> > On Saturday, October 18, 2025 02:42 CEST, Jimmy Hon <honyuenkwun@gmail.com> wrote:
> >> On Fri, Oct 17, 2025 at 10:15 AM Dragan Simic <dsimic@manjaro.org> wrote:
> >>> On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> >>>> On 2025/10/17 18:25, Dragan Simic wrote:
> >>>>> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> >>>>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>>>>>
> >>>>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> >>>>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> >>>>>> stable operation.
> >>>>>
> >>>>> Could you, please, provide more details about the troublesome eMMC
> >>>>> chip that gets identified as A3A444, i.e. what's the actual brand
> >>>>> and model?  Maybe you could send a picture of it?  It might also
> >>>>> help if you'd send the contents of "/sys/class/block/mmcblkX/device
> >>>>> /manfid" from your board (where "X" should equal two).
> >>>>
> >>>> Unfortunately I don't have this board nor this eMMC chip.
> >>>> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
> >>>> manfid is 0x0000d6.
> >>>
> >>> Thanks for responding and providing the details so quickly!
> >>>
> >>>>> I'm asking for that because I'd like to research it a bit further,
> >>>>> if possible, because some other eMMC chips that are also found on
> >>>>> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> >>>>> the A3A444 chip has some issues with the HS400 mode on its own,
> >>>>> i.e. the observed issues may not be caused by the board.
> >>>>
> >>>> Yes, it should be caused by this eMMC chip.
> >>>
> >>> I'd suggest that we move forward by "quirking off" the HS400 mode
> >>> for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> >>> downgrading the speed of the sdhci interface on the NanoPC-T6.
> >>>
> >>> That way, the other similar Foresee eMMC chip that's also found
> >>> on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> >>> the faster HS400 mode, while the troublesome A3A44 variant will
> >>> be downgraded to the HS200 globally for everyone's benefit.  It's
> >>> quite unlikely that the A3A44 variant fails to work reliable in
> >>> HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> >>> drivers should be a sane and safe choice.
> >>>
> >>> If you agree with dropping this patch, I'll be more than happy
> >>> to implement this HS200 quirk in the MMC drivers.
> >>>
> >>> As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> >>> eMMC Support List v1.84, [2] but the evidence says the opposite,
> >>> so we should react appropriately by adding this quirk.
> >>
> >> When adding the quirk for the A3A44, can we lower the max frequency
> >> and keep the HS400 mode instead?
> >> That's what the Fedora folks found works [3]. There's more test
> >> results in Armbian [4]
> > 
> > Are there any I/O performance tests that would prove that lowering
> > the HS400 frequency to 150 MHz ends up working significantly faster
> > than dropping the eMMC chip to HS200 mode?
> > 
> > I'm asking that because lowering the frequency looks much more like
> > there's some issue with the board, rather than the issue being the
> > eMMC chip's support for HS400 mode.  Thus, a quirk that would lower
> > the HS400 mode frequency would likely be frowned upon and rejected,
> > while a quirk that puts the chip into HS200 mode is much cleaner
> > and has much higher chances to be accepted.
> 
> I also have the NanoPC-T6 with one of the A3A444 eMMCs which suffers
> from I/O errors in the default HS400 mode. These are its details in
> /sys/block/mmcblk0/device/:
> manfid: 0x0000d6
> oemid: 0x0103
> name: A3A444
> fwrev: 0x1100000000000000
> hwrev: 0x0
> rev: 0x8

Thanks for reporting the same issue with the same board and
increasing our sample size to two. :)

> I wasn't sure if I was just unlucky to get a faulty chip, but seeing
> this thread it seems like a wider issue. On my board, limiting it to
> HS200 mode gets rid of the I/O errors, and it seems that lowering
> the frequency to 150MHz also avoids I/O errors.
> 
> I did a quick unscientific test with fio; HS400 Enhanced Strobe mode
> with a 150MHz clock gives slightly better performance than HS200:
> 
> HS200 mode:
> read: IOPS=697, BW=43.6MiB/s
> write: IOPS=697, BW=43.6MiB/s
> 
> HS400 mode with 150MHz clock:
> read: IOPS=805, BW=50.3MiB/s
> write: IOPS=799, BW=50.0MiB/s
> 
> so from my perspective, limiting the frequency would be a better fix
> than disabling HS400 entirely.

Thanks for running these tests!  The measured difference in the
I/O performance is about 15%, which surely isn't insignificant,
but IMHO it makes the proposed lowering of the eMMC chip to HS200
mode fall into the "good safety margin" bracket that I described
earlier.  I think it's better to sacrifice those 15% to stay on
the, hopefully, rock-solid side.

I've been thinking more about the 150 MHz HS400 and HS200 quirks,
and I'm afraid I'm even more sure that the 150 MHz HS400 quirk
would be frowned upon and rejected.  See, it does make it look
like a board-level issue, requiring a board-level fix, instead of
being a chip-level issue, for which a quirk would be fine.  The
acceptably low difference in the measured performance levels just
solidifies such a viewpoint, I'm afraid.

> It could also be of interest that the clock used apparently can't
> provide an exact 200MHz, e.g. in HS200 mode:
> 
> root@t6:~# cat /sys/kernel/debug/mmc0/ios
> clock:		200000000 Hz
> actual clock:	187500000 Hz
> vdd:		18 (3.0 ~ 3.1 V)
> bus mode:	2 (push-pull)
> chip select:	0 (don't care)
> power mode:	2 (on)
> bus width:	3 (8 bits)
> timing spec:	9 (mmc HS200)
> signal voltage:	1 (1.80 V)
> driver type:	0 (driver type B)

Thanks, that's also something to think about.

> > With all that in mind, if the resulting I/O performance difference
> > between 150 MHz HS400 and HS200 is within 15-20% or so, I'd highly
> > recommend that we still go with the HS200 quirk.  It also leaves
> > us with a nice safety margin, which is always good to have when
> > such hardware instability issues are worked around in software,
> > unless detailed eye diagrams, protocol dumps and whatnot can be
> > pulled and analyzed, in which case the resulting safety margin
> > can be much slimmer.
> > 
> > Ideally, we'd have a completely different board with the same
> > Foresee FEMDNN256G-A3A44 eMMC chip to test how reliably its HS400
> > mode works there, to see is it really up to this eMMC chip or up
> > to the board design, but I'm afraid we don't have that (easily)
> > available, so the only remaining option is to work with what's
> > actually available, which inevitably leads to a certain amount
> > of guesswork and some compromises.
> > 
> >>> [1] https://github.com/openwrt/openwrt/issues/18844
> >>> [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
> >> [3] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/MCSDYDQVOXS5AZMKA7LLY4QX7JXBWPCA/
> >> [4] https://github.com/armbian/build/pull/8736#issuecomment-3387760536

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Grzegorz,

On Sunday, October 19, 2025 12:05 CEST, Grzegorz Sterniczuk <grzegorz.sterniczuk@gmail.com> wrote:
> [image: image.png]
> [image: IMG_0471.jpeg]

Nice, thanks for the pictures!  BTW, I'm hoping to get the quirk
patch(es) done and submitted to the MLs in the next few days.  Of
course, I'll Cc your and everyone else's email addresses so you
can perform the required testing and provide Tested-by tags.

> On Fri, 17 Oct 2025 at 12:25, Dragan Simic <dsimic@manjaro.org> wrote:
> > On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com>
> > wrote:
> > > From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > >
> > > Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > > corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > > stable operation.
> >
> > Could you, please, provide more details about the troublesome eMMC
> > chip that gets identified as A3A444, i.e. what's the actual brand
> > and model?  Maybe you could send a picture of it?  It might also
> > help if you'd send the contents of "/sys/class/block/mmcblkX/device
> > /manfid" from your board (where "X" should equal two).
> >
> > I'm asking for that because I'd like to research it a bit further,
> > if possible, because some other eMMC chips that are also found on
> > the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> > the A3A444 chip has some issues with the HS400 mode on its own,
> > i.e. the observed issues may not be caused by the board.
> >
> > [1] https://github.com/openwrt/openwrt/issues/18844
> >
> > > Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > > Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> > > ---
> > >  arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > index fafeabe9adf9..5f63f38f7326 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > @@ -717,8 +717,7 @@ &sdhci {
> > >       no-sd;
> > >       non-removable;
> > >       max-frequency = <200000000>;
> > > -     mmc-hs400-1_8v;
> > > -     mmc-hs400-enhanced-strobe;
> > > +     mmc-hs200-1_8v;
> > >       status = "okay";
> > >  };

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Anand Moon]

Hi All,

On Sat, 18 Oct 2025 at 19:27, Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Hugh,
>
> On Saturday, October 18, 2025 14:14 CEST, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> > On 18/10/2025 09:30, Dragan Simic wrote:
> > > On Saturday, October 18, 2025 02:42 CEST, Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > >> On Fri, Oct 17, 2025 at 10:15 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > >>> On Friday, October 17, 2025 14:08 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > >>>> On 2025/10/17 18:25, Dragan Simic wrote:
> > >>>>> On Friday, October 17, 2025 09:39 CEST, Tianling Shen <cnsztl@gmail.com> wrote:
> > >>>>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > >>>>>>
> > >>>>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > >>>>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > >>>>>> stable operation.
> > >>>>>
> > >>>>> Could you, please, provide more details about the troublesome eMMC
> > >>>>> chip that gets identified as A3A444, i.e. what's the actual brand
> > >>>>> and model?  Maybe you could send a picture of it?  It might also
> > >>>>> help if you'd send the contents of "/sys/class/block/mmcblkX/device
> > >>>>> /manfid" from your board (where "X" should equal two).
> > >>>>
> > >>>> Unfortunately I don't have this board nor this eMMC chip.
> > >>>> I got the chip model from my friend, it's FORESEE FEMDNN256G-A3A44,
> > >>>> manfid is 0x0000d6.
> > >>>
> > >>> Thanks for responding and providing the details so quickly!
> > >>>
> > >>>>> I'm asking for that because I'd like to research it a bit further,
> > >>>>> if possible, because some other eMMC chips that are also found on
> > >>>>> the NanoPc-T6 seem to work fine in HS400 mode. [1]  It may be that
> > >>>>> the A3A444 chip has some issues with the HS400 mode on its own,
> > >>>>> i.e. the observed issues may not be caused by the board.
> > >>>>
> > >>>> Yes, it should be caused by this eMMC chip.
> > >>>
> > >>> I'd suggest that we move forward by "quirking off" the HS400 mode
> > >>> for the FEMDNN256G-A3A44 eMMC chip in the MMC drivers, instead of
> > >>> downgrading the speed of the sdhci interface on the NanoPC-T6.
> > >>>
> > >>> That way, the other similar Foresee eMMC chip that's also found
> > >>> on NanoPC-T6 boards, FEMDNN256G-A3A564, will continue to work in
> > >>> the faster HS400 mode, while the troublesome A3A44 variant will
> > >>> be downgraded to the HS200 globally for everyone's benefit.  It's
> > >>> quite unlikely that the A3A44 variant fails to work reliable in
> > >>> HS400 mode on the NanoPC-T6 only, so quirking it off in the MMC
> > >>> drivers should be a sane and safe choice.
> > >>>
> > >>> If you agree with dropping this patch, I'll be more than happy
> > >>> to implement this HS200 quirk in the MMC drivers.
> > >>>
> > >>> As a note, FEMDNN256G-A3A44 is found in the Rockchip Qualified
> > >>> eMMC Support List v1.84, [2] but the evidence says the opposite,
> > >>> so we should react appropriately by adding this quirk.
> > >>
> > >> When adding the quirk for the A3A44, can we lower the max frequency
> > >> and keep the HS400 mode instead?
> > >> That's what the Fedora folks found works [3]. There's more test
> > >> results in Armbian [4]
> > >
> > > Are there any I/O performance tests that would prove that lowering
> > > the HS400 frequency to 150 MHz ends up working significantly faster
> > > than dropping the eMMC chip to HS200 mode?
> > >
> > > I'm asking that because lowering the frequency looks much more like
> > > there's some issue with the board, rather than the issue being the
> > > eMMC chip's support for HS400 mode.  Thus, a quirk that would lower
> > > the HS400 mode frequency would likely be frowned upon and rejected,
> > > while a quirk that puts the chip into HS200 mode is much cleaner
> > > and has much higher chances to be accepted.
> >
> > I also have the NanoPC-T6 with one of the A3A444 eMMCs which suffers
> > from I/O errors in the default HS400 mode. These are its details in
> > /sys/block/mmcblk0/device/:
> > manfid: 0x0000d6
> > oemid: 0x0103
> > name: A3A444
> > fwrev: 0x1100000000000000
> > hwrev: 0x0
> > rev: 0x8
>
> Thanks for reporting the same issue with the same board and
> increasing our sample size to two. :)
>
> > I wasn't sure if I was just unlucky to get a faulty chip, but seeing
> > this thread it seems like a wider issue. On my board, limiting it to
> > HS200 mode gets rid of the I/O errors, and it seems that lowering
> > the frequency to 150MHz also avoids I/O errors.
> >
> > I did a quick unscientific test with fio; HS400 Enhanced Strobe mode
> > with a 150MHz clock gives slightly better performance than HS200:
> >
> > HS200 mode:
> > read: IOPS=697, BW=43.6MiB/s
> > write: IOPS=697, BW=43.6MiB/s
> >
> > HS400 mode with 150MHz clock:
> > read: IOPS=805, BW=50.3MiB/s
> > write: IOPS=799, BW=50.0MiB/s
> >
> > so from my perspective, limiting the frequency would be a better fix
> > than disabling HS400 entirely.
>
> Thanks for running these tests!  The measured difference in the
> I/O performance is about 15%, which surely isn't insignificant,
> but IMHO it makes the proposed lowering of the eMMC chip to HS200
> mode fall into the "good safety margin" bracket that I described
> earlier.  I think it's better to sacrifice those 15% to stay on
> the, hopefully, rock-solid side.
>
> I've been thinking more about the 150 MHz HS400 and HS200 quirks,
> and I'm afraid I'm even more sure that the 150 MHz HS400 quirk
> would be frowned upon and rejected.  See, it does make it look
> like a board-level issue, requiring a board-level fix, instead of
> being a chip-level issue, for which a quirk would be fine.  The
> acceptably low difference in the measured performance levels just
> solidifies such a viewpoint, I'm afraid.
>
> > It could also be of interest that the clock used apparently can't
> > provide an exact 200MHz, e.g. in HS200 mode:
> >
> > root@t6:~# cat /sys/kernel/debug/mmc0/ios
> > clock:                200000000 Hz
> > actual clock: 187500000 Hz
> > vdd:          18 (3.0 ~ 3.1 V)
> > bus mode:     2 (push-pull)
> > chip select:  0 (don't care)
> > power mode:   2 (on)
> > bus width:    3 (8 bits)
> > timing spec:  9 (mmc HS200)
> > signal voltage:       1 (1.80 V)
> > driver type:  0 (driver type B)
>
> Thanks, that's also something to think about.
>
> > > With all that in mind, if the resulting I/O performance difference
> > > between 150 MHz HS400 and HS200 is within 15-20% or so, I'd highly
> > > recommend that we still go with the HS200 quirk.  It also leaves
> > > us with a nice safety margin, which is always good to have when
> > > such hardware instability issues are worked around in software,
> > > unless detailed eye diagrams, protocol dumps and whatnot can be
> > > pulled and analyzed, in which case the resulting safety margin
> > > can be much slimmer.
> > >
> > > Ideally, we'd have a completely different board with the same
> > > Foresee FEMDNN256G-A3A44 eMMC chip to test how reliably its HS400
> > > mode works there, to see is it really up to this eMMC chip or up
> > > to the board design, but I'm afraid we don't have that (easily)
> > > available, so the only remaining option is to work with what's
> > > actually available, which inevitably leads to a certain amount
> > > of guesswork and some compromises.
> > >
> > >>> [1] https://github.com/openwrt/openwrt/issues/18844
> > >>> [2] https://dl.radxa.com/rock5/hw/RKeMMCSupportList%20Ver1.84_20240815.pdf
> > >> [3] https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/MCSDYDQVOXS5AZMKA7LLY4QX7JXBWPCA/
> > >> [4] https://github.com/armbian/build/pull/8736#issuecomment-3387760536
>

Would you consider the following patch?

As per the Rockchip RK3588S SoC Technical Reference Manual (TRM) Part 1,
chapter 21.6, Interface Description, the eMMC signals require careful handling
to ensure signal integrity.

I2C2_SCL_M2 I/O EMMC_RSTN/I2C2_SCL_M2/UART5_RTSN_M1/GPIO2_A3_d
BUS_IOC_GPIO2A_IOMUX_SEL_L[15:12]=0x9
I2C2_SDA_M2 I/O EMMC_DATA_STROBE/I2C2_SDA_M2/UART5_CTSN_M1/GPIO2_A2_d
BUS_IOC_GPIO2A_IOMUX_SEL_L[11:8]=0x9

$ git diff .
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
index 6584d73660f6..f60a1d8be0ef 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
@@ -327,7 +327,7 @@ emmc {
                emmc_rstnout: emmc-rstnout {
                        rockchip,pins =
                                /* emmc_rstn */
-                               <2 RK_PA3 1 &pcfg_pull_none>;
+                               <2 RK_PA3 1 &pcfg_pull_down_drv_level_2>;
                };

                /omit-if-no-ref/
@@ -369,7 +369,7 @@ emmc_cmd: emmc-cmd {
                emmc_data_strobe: emmc-data-strobe {
                        rockchip,pins =
                                /* emmc_data_strobe */
-                               <2 RK_PA2 1 &pcfg_pull_down>;
+                               <2 RK_PA2 1 &pcfg_pull_down_drv_level_2>;
                };
        };

Thanks
-Anand

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Anand,

On Sunday, October 19, 2025 19:25 CEST, Anand Moon <linux.amoon@gmail.com> wrote:
> Would you consider the following patch?
> 
> As per the Rockchip RK3588S SoC Technical Reference Manual (TRM) Part 1,
> chapter 21.6, Interface Description, the eMMC signals require careful handling
> to ensure signal integrity.
> 
> I2C2_SCL_M2 I/O EMMC_RSTN/I2C2_SCL_M2/UART5_RTSN_M1/GPIO2_A3_d
> BUS_IOC_GPIO2A_IOMUX_SEL_L[15:12]=0x9
> I2C2_SDA_M2 I/O EMMC_DATA_STROBE/I2C2_SDA_M2/UART5_CTSN_M1/GPIO2_A2_d
> BUS_IOC_GPIO2A_IOMUX_SEL_L[11:8]=0x9
> 
> $ git diff .
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> index 6584d73660f6..f60a1d8be0ef 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> @@ -327,7 +327,7 @@ emmc {
>                 emmc_rstnout: emmc-rstnout {
>                         rockchip,pins =
>                                 /* emmc_rstn */
> -                               <2 RK_PA3 1 &pcfg_pull_none>;
> +                               <2 RK_PA3 1 &pcfg_pull_down_drv_level_2>;
>                 };
> 
>                 /omit-if-no-ref/
> @@ -369,7 +369,7 @@ emmc_cmd: emmc-cmd {
>                 emmc_data_strobe: emmc-data-strobe {
>                         rockchip,pins =
>                                 /* emmc_data_strobe */
> -                               <2 RK_PA2 1 &pcfg_pull_down>;
> +                               <2 RK_PA2 1 &pcfg_pull_down_drv_level_2>;
>                 };
>         };

Frankly, I'm not really sure how would such changes do something
good regarding the eMMC signal integrity?  In general, signal
integrity depends mostly on the routing of the PCB traces, which
is purely hardware design.  Sure, termination of data lines also
plays a significant role, but that surely isn't at play here.

Moreover, the eMMC RSTn line is already pulled high to VCCIO in
the reference RK3588 design, so pulling it down in the SoC itself
would be pretty much wrong thing to do.

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Shawn Lin]

Hi Tianling

On 2025/10/17 Friday 15:39, Tianling Shen wrote:
> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> 
> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> stable operation.

May I ask you to test another patch I just posted to see if it fixes
your issue?

https://patchwork.kernel.org/project/linux-mmc/patch/1760924981-52339-1-git-send-email-shawn.lin@rock-chips.com/


> 
> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> ---
>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> index fafeabe9adf9..5f63f38f7326 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> @@ -717,8 +717,7 @@ &sdhci {
>   	no-sd;
>   	non-removable;
>   	max-frequency = <200000000>;
> -	mmc-hs400-1_8v;
> -	mmc-hs400-enhanced-strobe;
> +	mmc-hs200-1_8v;
>   	status = "okay";
>   };
>   

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Anand Moon]

Hi Dragan,

On Sun, 19 Oct 2025 at 23:40, Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Anand,
>
> On Sunday, October 19, 2025 19:25 CEST, Anand Moon <linux.amoon@gmail.com> wrote:
> > Would you consider the following patch?
> >
> > As per the Rockchip RK3588S SoC Technical Reference Manual (TRM) Part 1,
> > chapter 21.6, Interface Description, the eMMC signals require careful handling
> > to ensure signal integrity.
> >
> > I2C2_SCL_M2 I/O EMMC_RSTN/I2C2_SCL_M2/UART5_RTSN_M1/GPIO2_A3_d
> > BUS_IOC_GPIO2A_IOMUX_SEL_L[15:12]=0x9
> > I2C2_SDA_M2 I/O EMMC_DATA_STROBE/I2C2_SDA_M2/UART5_CTSN_M1/GPIO2_A2_d
> > BUS_IOC_GPIO2A_IOMUX_SEL_L[11:8]=0x9
> >
> > $ git diff .
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > index 6584d73660f6..f60a1d8be0ef 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > @@ -327,7 +327,7 @@ emmc {
> >                 emmc_rstnout: emmc-rstnout {
> >                         rockchip,pins =
> >                                 /* emmc_rstn */
> > -                               <2 RK_PA3 1 &pcfg_pull_none>;
> > +                               <2 RK_PA3 1 &pcfg_pull_down_drv_level_2>;
> >                 };
> >
> >                 /omit-if-no-ref/
> > @@ -369,7 +369,7 @@ emmc_cmd: emmc-cmd {
> >                 emmc_data_strobe: emmc-data-strobe {
> >                         rockchip,pins =
> >                                 /* emmc_data_strobe */
> > -                               <2 RK_PA2 1 &pcfg_pull_down>;
> > +                               <2 RK_PA2 1 &pcfg_pull_down_drv_level_2>;
> >                 };
> >         };
>
> Frankly, I'm not really sure how would such changes do something
> good regarding the eMMC signal integrity?  In general, signal
> integrity depends mostly on the routing of the PCB traces, which
> is purely hardware design.  Sure, termination of data lines also
> plays a significant role, but that surely isn't at play here.
>
It is necessary to enhance the signal quality from the controller to
the eMMC module

> Moreover, the eMMC RSTn line is already pulled high to VCCIO in
> the reference RK3588 design, so pulling it down in the SoC itself
> would be pretty much wrong thing to do.
>
It is specified in the TRM that this is only applicable during
initialization.as per my understanding.

Thanks
-Anand

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

Hi Shawn,

On 2025/10/20 9:53, Shawn Lin wrote:
> Hi Tianling
> 
> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>
>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>> stable operation.
> 
> May I ask you to test another patch I just posted to see if it fixes
> your issue?
> 
> https://patchwork.kernel.org/project/linux-mmc/patch/1760924981-52339-1- 
> git-send-email-shawn.lin@rock-chips.com/

Thank you for the patch! I will ask my friend to test it but he uses 
this board as a home router, so it may take a few days or weeks to 
report the result.

Thanks,
Tianling.

> 
> 
>>
>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/ 
>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> index fafeabe9adf9..5f63f38f7326 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> @@ -717,8 +717,7 @@ &sdhci {
>>       no-sd;
>>       non-removable;
>>       max-frequency = <200000000>;
>> -    mmc-hs400-1_8v;
>> -    mmc-hs400-enhanced-strobe;
>> +    mmc-hs200-1_8v;
>>       status = "okay";
>>   };
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Shawn Lin]

+ Hugh Cole-Baker who seems also suffer from this issue

在 2025/10/20 星期一 12:44, Tianling Shen 写道:
> Hi Shawn,
> 
> On 2025/10/20 9:53, Shawn Lin wrote:
>> Hi Tianling
>>
>> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>
>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>>> stable operation.
>>
>> May I ask you to test another patch I just posted to see if it fixes
>> your issue?
>>
>> https://patchwork.kernel.org/project/linux-mmc/ 
>> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
> 
> Thank you for the patch! I will ask my friend to test it but he uses 
> this board as a home router, so it may take a few days or weeks to 
> report the result.
 > > Thanks,
> Tianling.
> 
>>
>>
>>>
>>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>>> ---
>>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/ 
>>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> index fafeabe9adf9..5f63f38f7326 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> @@ -717,8 +717,7 @@ &sdhci {
>>>       no-sd;
>>>       non-removable;
>>>       max-frequency = <200000000>;
>>> -    mmc-hs400-1_8v;
>>> -    mmc-hs400-enhanced-strobe;
>>> +    mmc-hs200-1_8v;
>>>       status = "okay";
>>>   };
>>
> 
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Anand,

On Monday, October 20, 2025 05:13 CEST, Anand Moon <linux.amoon@gmail.com> wrote:
> On Sun, 19 Oct 2025 at 23:40, Dragan Simic <dsimic@manjaro.org> wrote:
> > On Sunday, October 19, 2025 19:25 CEST, Anand Moon <linux.amoon@gmail.com> wrote:
> > > Would you consider the following patch?
> > >
> > > As per the Rockchip RK3588S SoC Technical Reference Manual (TRM) Part 1,
> > > chapter 21.6, Interface Description, the eMMC signals require careful handling
> > > to ensure signal integrity.
> > >
> > > I2C2_SCL_M2 I/O EMMC_RSTN/I2C2_SCL_M2/UART5_RTSN_M1/GPIO2_A3_d
> > > BUS_IOC_GPIO2A_IOMUX_SEL_L[15:12]=0x9
> > > I2C2_SDA_M2 I/O EMMC_DATA_STROBE/I2C2_SDA_M2/UART5_CTSN_M1/GPIO2_A2_d
> > > BUS_IOC_GPIO2A_IOMUX_SEL_L[11:8]=0x9
> > >
> > > $ git diff .
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > > index 6584d73660f6..f60a1d8be0ef 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
> > > @@ -327,7 +327,7 @@ emmc {
> > >                 emmc_rstnout: emmc-rstnout {
> > >                         rockchip,pins =
> > >                                 /* emmc_rstn */
> > > -                               <2 RK_PA3 1 &pcfg_pull_none>;
> > > +                               <2 RK_PA3 1 &pcfg_pull_down_drv_level_2>;
> > >                 };
> > >
> > >                 /omit-if-no-ref/
> > > @@ -369,7 +369,7 @@ emmc_cmd: emmc-cmd {
> > >                 emmc_data_strobe: emmc-data-strobe {
> > >                         rockchip,pins =
> > >                                 /* emmc_data_strobe */
> > > -                               <2 RK_PA2 1 &pcfg_pull_down>;
> > > +                               <2 RK_PA2 1 &pcfg_pull_down_drv_level_2>;
> > >                 };
> > >         };
> >
> > Frankly, I'm not really sure how would such changes do something
> > good regarding the eMMC signal integrity?  In general, signal
> > integrity depends mostly on the routing of the PCB traces, which
> > is purely hardware design.  Sure, termination of data lines also
> > plays a significant role, but that surely isn't at play here.
> >
> It is necessary to enhance the signal quality from the controller to
> the eMMC module

Well, yes, but the proposed change almost surely isn't a way
to achieve that.  Maybe I'm missing something, but it looks like
a pretty much random change to me.

> > Moreover, the eMMC RSTn line is already pulled high to VCCIO in
> > the reference RK3588 design, so pulling it down in the SoC itself
> > would be pretty much wrong thing to do.
> >
> It is specified in the TRM that this is only applicable during
> initialization.as per my understanding.

It doesn't matter what the TRM says in this case, because the
board-level pull-up and SoC-level pull-down remain the same at
all times, and having both a pull-up and a pull-down at the same
time is a typical example of what shouldn't be happening on some
line until that's intentional and the pull-ups and pull-downs
deliberately have different strengths.

Anyway, let's see will the patch that Shawn sent [1] fix this
issue (by the way, thanks, Shawn!).  I'll hold the A3A444 quirk
patch(es) off until Tianling's friend and Hugh find the time to
test Shawn's patch.

[1] https://patchwork.kernel.org/project/linux-mmc/patch/1760924981-52339-1-git-send-email-shawn.lin@rock-chips.com/

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

+ Jianfeng

On 2025/10/20 12:44, Tianling Shen wrote:
> Hi Shawn,
> 
> On 2025/10/20 9:53, Shawn Lin wrote:
>> Hi Tianling
>>
>> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>
>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>>> stable operation.
>>
>> May I ask you to test another patch I just posted to see if it fixes
>> your issue?
>>
>> https://patchwork.kernel.org/project/linux-mmc/ 
>> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
> 
> Thank you for the patch! I will ask my friend to test it but he uses 
> this board as a home router, so it may take a few days or weeks to 
> report the result.

Hi all, sorry for the late. My friend has tested this patch and it works 
fine after 50 times dd operation. A big thanks to Shawn!

And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX 
board to lower down the mmc speed, could you please check if this patch 
also fixes your issue?

Thanks,
Tianling.

1. 
https://lore.kernel.org/linux-rockchip/20250228143341.70244-1-liujianfeng1994@gmail.com/

> 
> Thanks,
> Tianling.
> 
>>
>>
>>>
>>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>>> ---
>>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/ 
>>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> index fafeabe9adf9..5f63f38f7326 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>> @@ -717,8 +717,7 @@ &sdhci {
>>>       no-sd;
>>>       non-removable;
>>>       max-frequency = <200000000>;
>>> -    mmc-hs400-1_8v;
>>> -    mmc-hs400-enhanced-strobe;
>>> +    mmc-hs200-1_8v;
>>>       status = "okay";
>>>   };
>>
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Jianfeng Liu]

Hi Tianling,

On Tue, 28 Oct 2025 01:34:25 +0800, Tianling Shen wrote:
>>> May I ask you to test another patch I just posted to see if it fixes
>>> your issue?
>>>
>>> https://patchwork.kernel.org/project/linux-mmc/ 
>>> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
>> 
>> Thank you for the patch! I will ask my friend to test it but he uses 
>> this board as a home router, so it may take a few days or weeks to 
>> report the result.
>
>Hi all, sorry for the late. My friend has tested this patch and it works 
>fine after 50 times dd operation. A big thanks to Shawn!
>
>And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX 
>board to lower down the mmc speed, could you please check if this patch 
>also fixes your issue?

I don't have rock 5 itx near my hand to test, but I have another board
ROCK 5B with similar issue. And after applying the patch from Shawn, this
board can run HS400 mode with max freq 200000000.

I will test on rock 5 itx later when I have chance.

Best regards,
Jianfeng

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Heiko Stuebner]

Am Montag, 27. Oktober 2025, 18:34:25 Mitteleuropäische Normalzeit schrieb Tianling Shen:
> + Jianfeng
> 
> On 2025/10/20 12:44, Tianling Shen wrote:
> > Hi Shawn,
> > 
> > On 2025/10/20 9:53, Shawn Lin wrote:
> >> Hi Tianling
> >>
> >> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
> >>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>>
> >>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> >>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> >>> stable operation.
> >>
> >> May I ask you to test another patch I just posted to see if it fixes
> >> your issue?
> >>
> >> https://patchwork.kernel.org/project/linux-mmc/ 
> >> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
> > 
> > Thank you for the patch! I will ask my friend to test it but he uses 
> > this board as a home router, so it may take a few days or weeks to 
> > report the result.
> 
> Hi all, sorry for the late. My friend has tested this patch and it works 
> fine after 50 times dd operation. A big thanks to Shawn!

So I guess, we don't need the patch reducing the speed anymore, right?


Thanks
Heiko


> And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX 
> board to lower down the mmc speed, could you please check if this patch 
> also fixes your issue?
> 
> Thanks,
> Tianling.
> 
> 1. 
> https://lore.kernel.org/linux-rockchip/20250228143341.70244-1-liujianfeng1994@gmail.com/
> 
> > 
> > Thanks,
> > Tianling.
> > 
> >>
> >>
> >>>
> >>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> >>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> >>> ---
> >>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> >>>   1 file changed, 1 insertion(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/ 
> >>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>> index fafeabe9adf9..5f63f38f7326 100644
> >>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> >>> @@ -717,8 +717,7 @@ &sdhci {
> >>>       no-sd;
> >>>       non-removable;
> >>>       max-frequency = <200000000>;
> >>> -    mmc-hs400-1_8v;
> >>> -    mmc-hs400-enhanced-strobe;
> >>> +    mmc-hs200-1_8v;
> >>>       status = "okay";
> >>>   };
> >>
> > 
> 
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Tianling Shen]

Hi Heiko,

On 2025/11/1 19:54, Heiko Stuebner wrote:
> Am Montag, 27. Oktober 2025, 18:34:25 Mitteleuropäische Normalzeit schrieb Tianling Shen:
>> + Jianfeng
>>
>> On 2025/10/20 12:44, Tianling Shen wrote:
>>> Hi Shawn,
>>>
>>> On 2025/10/20 9:53, Shawn Lin wrote:
>>>> Hi Tianling
>>>>
>>>> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
>>>>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>>>
>>>>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
>>>>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
>>>>> stable operation.
>>>>
>>>> May I ask you to test another patch I just posted to see if it fixes
>>>> your issue?
>>>>
>>>> https://patchwork.kernel.org/project/linux-mmc/
>>>> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
>>>
>>> Thank you for the patch! I will ask my friend to test it but he uses
>>> this board as a home router, so it may take a few days or weeks to
>>> report the result.
>>
>> Hi all, sorry for the late. My friend has tested this patch and it works
>> fine after 50 times dd operation. A big thanks to Shawn!
> 
> So I guess, we don't need the patch reducing the speed anymore, right?

Yes! ;)

Thanks,
Tianling.

> 
> 
> Thanks
> Heiko
> 
> 
>> And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX
>> board to lower down the mmc speed, could you please check if this patch
>> also fixes your issue?
>>
>> Thanks,
>> Tianling.
>>
>> 1.
>> https://lore.kernel.org/linux-rockchip/20250228143341.70244-1-liujianfeng1994@gmail.com/
>>
>>>
>>> Thanks,
>>> Tianling.
>>>
>>>>
>>>>
>>>>>
>>>>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
>>>>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>>>>> ---
>>>>>    arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
>>>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/
>>>>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>>> index fafeabe9adf9..5f63f38f7326 100644
>>>>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>>>>> @@ -717,8 +717,7 @@ &sdhci {
>>>>>        no-sd;
>>>>>        non-removable;
>>>>>        max-frequency = <200000000>;
>>>>> -    mmc-hs400-1_8v;
>>>>> -    mmc-hs400-enhanced-strobe;
>>>>> +    mmc-hs200-1_8v;
>>>>>        status = "okay";
>>>>>    };
>>>>
>>>
>>
>>
> 
> 
> 
> 

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Dragan Simic]

Hello Heiko,

On Saturday, November 01, 2025 12:54 CET, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Montag, 27. Oktober 2025, 18:34:25 Mitteleuropäische Normalzeit schrieb Tianling Shen:
> > On 2025/10/20 12:44, Tianling Shen wrote:
> > > On 2025/10/20 9:53, Shawn Lin wrote:
> > >> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
> > >>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > >>>
> > >>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > >>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > >>> stable operation.
> > >>
> > >> May I ask you to test another patch I just posted to see if it fixes
> > >> your issue?
> > >>
> > >> https://patchwork.kernel.org/project/linux-mmc/ 
> > >> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
> > > 
> > > Thank you for the patch! I will ask my friend to test it but he uses 
> > > this board as a home router, so it may take a few days or weeks to 
> > > report the result.
> > 
> > Hi all, sorry for the late. My friend has tested this patch and it works 
> > fine after 50 times dd operation. A big thanks to Shawn!
> 
> So I guess, we don't need the patch reducing the speed anymore, right?

Exactly, the approach of lowering the speed of eMMC to improve
its reliability is no longer needed, thanks to Shawn correcting
the DLL_STRBIN_TAPNUM_DEFAULT value in the above-linked patch.

We just need to test does HS400 work on the ROCK 5 ITX reliably
as well, so the previous lowering to HS200 in commit b36402e4a077
("arm64: dts: rockchip: slow down emmc freq for rock 5 itx", 2025-
02-28) could be reverted as no longer needed.

> > And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX 
> > board to lower down the mmc speed, could you please check if this patch 
> > also fixes your issue?
> > 
> > [1] https://lore.kernel.org/linux-rockchip/20250228143341.70244-1-liujianfeng1994@gmail.com/
> > 
> > >>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > >>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> > >>> ---
> > >>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> > >>>   1 file changed, 1 insertion(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/ 
> > >>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > >>> index fafeabe9adf9..5f63f38f7326 100644
> > >>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > >>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > >>> @@ -717,8 +717,7 @@ &sdhci {
> > >>>       no-sd;
> > >>>       non-removable;
> > >>>       max-frequency = <200000000>;
> > >>> -    mmc-hs400-1_8v;
> > >>> -    mmc-hs400-enhanced-strobe;
> > >>> +    mmc-hs200-1_8v;
> > >>>       status = "okay";
> > >>>   };

Re: [PATCH] arm64: dts: rockchip: fix eMMC corruption on NanoPC-T6 with A3A444 chips

[Anand Moon]

Hi All,

On Sat, 1 Nov 2025 at 18:21, Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Heiko,
>
> On Saturday, November 01, 2025 12:54 CET, Heiko Stuebner <heiko@sntech.de> wrote:
> > Am Montag, 27. Oktober 2025, 18:34:25 Mitteleuropäische Normalzeit schrieb Tianling Shen:
> > > On 2025/10/20 12:44, Tianling Shen wrote:
> > > > On 2025/10/20 9:53, Shawn Lin wrote:
> > > >> On 2025/10/17 Friday 15:39, Tianling Shen wrote:
> > > >>> From: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > > >>>
> > > >>> Some NanoPC-T6 boards with A3A444 eMMC chips experience I/O errors and
> > > >>> corruption when using HS400 mode. Downgrade to HS200 mode to ensure
> > > >>> stable operation.
> > > >>
> > > >> May I ask you to test another patch I just posted to see if it fixes
> > > >> your issue?
> > > >>
> > > >> https://patchwork.kernel.org/project/linux-mmc/
> > > >> patch/1760924981-52339-1- git-send-email-shawn.lin@rock-chips.com/
> > > >
> > > > Thank you for the patch! I will ask my friend to test it but he uses
> > > > this board as a home router, so it may take a few days or weeks to
> > > > report the result.
> > >
> > > Hi all, sorry for the late. My friend has tested this patch and it works
> > > fine after 50 times dd operation. A big thanks to Shawn!
> >
> > So I guess, we don't need the patch reducing the speed anymore, right?
>
> Exactly, the approach of lowering the speed of eMMC to improve
> its reliability is no longer needed, thanks to Shawn correcting
> the DLL_STRBIN_TAPNUM_DEFAULT value in the above-linked patch.
>
> We just need to test does HS400 work on the ROCK 5 ITX reliably
> as well, so the previous lowering to HS200 in commit b36402e4a077
> ("arm64: dts: rockchip: slow down emmc freq for rock 5 itx", 2025-
> 02-28) could be reverted as no longer needed.
>
> > > And hi Jianfeng, I found you made a similiar patch[1] for the ROCK 5 ITX
> > > board to lower down the mmc speed, could you please check if this patch
> > > also fixes your issue?
> > >
> > > [1] https://lore.kernel.org/linux-rockchip/20250228143341.70244-1-liujianfeng1994@gmail.com/
> > >
> > > >>> Signed-off-by: Grzegorz Sterniczuk <grzegorz@sternicz.uk>
> > > >>> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
> > > >>> ---
> > > >>>   arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 3 +--
> > > >>>   1 file changed, 1 insertion(+), 2 deletions(-)
> > > >>>
> > > >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/
> > > >>> arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > >>> index fafeabe9adf9..5f63f38f7326 100644
> > > >>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > >>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
> > > >>> @@ -717,8 +717,7 @@ &sdhci {
> > > >>>       no-sd;
> > > >>>       non-removable;
> > > >>>       max-frequency = <200000000>;
> > > >>> -    mmc-hs400-1_8v;
> > > >>> -    mmc-hs400-enhanced-strobe;
> > > >>> +    mmc-hs200-1_8v;
> > > >>>       status = "okay";
> > > >>>   };
>
You can also try this patch, which enables stober in the eMMC controller..

diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index eebd45389956..62c9faf8ec85 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -77,6 +77,10 @@
 #define CV18XX_RETRY_TUNING_MAX                        50

 /* Rockchip specific Registers */
+#define DWCMSHC_EMMC_CTRL              0x52c
+#define  EMMC_CTRL_CARD_IS_EMMC        BIT(0)
+#define  EMMC_CTRL_ENH_STROBE_ENABLE   BIT(8)
+
 #define DWCMSHC_EMMC_DLL_CTRL          0x800
 #define DWCMSHC_EMMC_DLL_RXCLK         0x804
 #define DWCMSHC_EMMC_DLL_TXCLK         0x808
@@ -660,6 +664,12 @@ static void dwcmshc_rk3568_set_clock(struct
sdhci_host *host, unsigned int clock
                        DLL_CMDOUT_TAPNUM_90_DEGREES |
                        DLL_CMDOUT_TAPNUM_FROM_SW;
                sdhci_writel(host, extra, DECMSHC_EMMC_DLL_CMDOUT);
+
+               extra = sdhci_readl(host, DWCMSHC_EMMC_CTRL);
+               if (extra & EMMC_CTRL_CARD_IS_EMMC) {
+                       extra |= EMMC_CTRL_ENH_STROBE_ENABLE;
+                       sdhci_writel(host, extra, DWCMSHC_EMMC_CTRL);
+               }
        }

        extra = DWCMSHC_EMMC_DLL_DLYENA |

Thamks
-Anand