@prahal I can confirm that with those changes to the helios64 dtb emmc can be accessed with hs400 speed again. I tried that with linux 6.1.11 (reading and writing to emmc without CQE errors). Thank you very much for solving that issue.

 

# cat /proc/version
Linux version 6.1.11-rockchip64 (root@52d12ff355f0) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #23.02.2 SMP PREEMPT Sat Feb 18 00:08:25 UTC 2023

# hdparm -tT /dev/mmcblk1

/dev/mmcblk1:
 Timing cached reads:   2796 MB in  2.00 seconds = 1398.63 MB/sec
 Timing buffered disk reads: 664 MB in  3.01 seconds = 220.81 MB/sec

 

changes to rk3399-kobol-helios64.dtb:

 

added to phy@f780:
rockchip,enable-strobe-pulldown;

added to mmc@fe330000:
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;

deleted from mmc@fe330000:
mmc-hs200-1_8v;

 

Edited December 17, 20232 yr by ebin-dev

On 12/17/2023 at 7:52 PM, ebin-dev said:

deleted from mmc@fe330000:
mmc-hs200-1_8v;

No need to remove this one (you can have both hs400 and hs200 enabled).

Thank you for the feedback.

@prahal The fix also works with linux 5.15.93.

On 12/22/2023 at 12:13 PM, ebin-dev said:

The fix also works with linux 5.15.93.

Thanks a lot for the testing work.

I am uneasy about sending this push request upstream, maybe only in armbian at first.

The proper fix could end up being inverting the pulldown default value for the initial commit https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e in mainline.

 

    As was done for rk3588 boards:  "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 "

With comment:

JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees

 

But that would requires board designers or the author of the above rk3588 commit to confirm the same is done on most rk3399 boards.

46 minutes ago, prahal said:

I am uneasy about sending this push request upstream, maybe only in armbian at first.

 

I have noticed that your three pull requests made it into Armbian.  We may now receive stable Armbian images for Helios64 again without having to revert u-boot to older versions. Thank you very much !