ebin-dev Posted December 17, 2023 Author Share Posted December 17, 2023 (edited) @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, 2023 by ebin-dev 0 Quote Link to comment Share on other sites More sharing options...
prahal Posted December 20, 2023 Share Posted December 20, 2023 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. 0 Quote Link to comment Share on other sites More sharing options...
ebin-dev Posted December 22, 2023 Author Share Posted December 22, 2023 @prahal The fix also works with linux 5.15.93. 0 Quote Link to comment Share on other sites More sharing options...
prahal Posted December 24, 2023 Share Posted December 24, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
ebin-dev Posted December 24, 2023 Author Share Posted December 24, 2023 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 ! 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.