Nanopc-T4 - New kernel 22.02 generates issues on mmc2 and makes system not properly working

[Viper]

Armbianmonitor:

http://ix.io/3Rw6

Hi,

since latest upgrade to new kernel 22.02 stable the system becomes unstable. There are issues writing to mmc2 and "EXT4-fs (mmcblk2p1): Remounting filesystem read-only". This does not allow most of the apps to work properly (e.g. openmediavault stops working)

I tried to switch back to previous kernel version through armbian-config but that does not work too

Pls help.

Thanks

[haajee]

I got the problem with my orange pi4 that even the network doesn't work and got a lot of errors in the display. network connection stops working also!

[fraz0815]

HS400 for onboard emmc broke somewhere between 5.10 and 5.15 on nanopct4 (and a few others afaik).

 

If you boot from SD card, at first everything looks great, because CD GPIO is set:

 

dmesg | grep mmc   
[    0.104269] platform ff770000.syscon:phy@f780: Fixing up cyclic dependency with fe330000.mmc
[    1.647160] dwmmc_rockchip fe310000.mmc: IDMAC supports 32-bit address mode.
[    1.647892] dwmmc_rockchip fe310000.mmc: Using internal DMA controller.
[    1.648508] dwmmc_rockchip fe310000.mmc: Version ID is 270a
[    1.649120] dwmmc_rockchip fe310000.mmc: DW MMC controller at irq 32,32 bit host data width,256 deep fifo
[    1.649759] mmc2: CQHCI version 5.10
[    1.676546] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
[    1.750545] mmc2: Command Queue Engine enabled
[    1.750984] mmc2: new HS400 MMC card at address 0001
[    1.752515] mmcblk2: mmc2:0001 AJTD4R 14.6 GiB 
[    1.755656]  mmcblk2: p1
[    1.756614] mmcblk2boot0: mmc2:0001 AJTD4R 4.00 MiB 
[    1.759327] mmcblk2boot1: mmc2:0001 AJTD4R 4.00 MiB 
[    1.761918] mmcblk2rpmb: mmc2:0001 AJTD4R 4.00 MiB, chardev (241:0)
[    2.956947] dwmmc_rockchip fe320000.mmc: IDMAC supports 32-bit address mode.
[    2.957632] dwmmc_rockchip fe320000.mmc: Using internal DMA controller.
[    2.957769] dwmmc_rockchip fe310000.mmc: IDMAC supports 32-bit address mode.
[    2.958230] dwmmc_rockchip fe320000.mmc: Version ID is 270a
[    2.958902] dwmmc_rockchip fe310000.mmc: Using internal DMA controller.
[    2.959430] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 33,32 bit host data width,256 deep fifo
[    2.960026] dwmmc_rockchip fe310000.mmc: Version ID is 270a
[    2.961467] dwmmc_rockchip fe320000.mmc: Got CD GPIO
[    2.962269] dwmmc_rockchip fe310000.mmc: DW MMC controller at irq 32,32 bit host data width,256 deep fifo
[    2.965754] dwmmc_rockchip fe310000.mmc: allocated mmc-pwrseq
[    2.966290] mmc_host mmc0: card is non-removable.
[    2.976026] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    2.979901] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    3.071609] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[    3.092749] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[    3.250481] dwmmc_rockchip fe320000.mmc: Successfully tuned phase to 218
[    3.251121] mmc1: new ultra high speed SDR104 SDHC card at address aaaa
[    3.253087] mmcblk1: mmc1:aaaa SC32G 29.7 GiB 
[    3.258541]  mmcblk1: p1
[    3.360734] dwmmc_rockchip fe310000.mmc: Successfully tuned phase to 211
[    3.367492] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[    6.616181] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.friendlyarm,nanopc-t4.bin failed with error -2
[    6.620630] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4356-sdio.friendlyarm,nanopc-t4.txt failed with error -2
[    6.691061] systemd[1]: Mounting /media/mmcboot...
[    6.708099] EXT4-fs (mmcblk1p1): mounted filesystem with writeback data mode. Opts: commit=600,errors=remount-ro. Quota mode: none.
[    6.729629] systemd[1]: Mounted /media/mmcboot.

 

But simple tasks like formatting, keep crashing: 
 

sudo mkfs.ext4 /dev/mmcblk2p1 
mke2fs 1.46.5 (30-Dec-2021)
/dev/mmcblk2p1 contains a ext4 file system
	last mounted on /home/nano/emmc on Fri Mar 11 04:31:46 2022
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 3812864 4k blocks and 954720 inodes
Filesystem UUID: 38f1e32f-13ca-4e77-b8ec-2691d7065062
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system

 

dmesg
[  201.765056] mmc2: running CQE recovery
[  370.548084] mmc2: running CQE recovery
[  370.615609] mmc2: running CQE recovery
[  370.623274] mmc2: running CQE recovery
[  370.631096] mmc2: running CQE recovery
[  370.638104] mmc2: running CQE recovery
[  370.640653] I/O error, dev mmcblk2, sector 12890136 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  370.646122] mmc2: running CQE recovery
[  370.653205] mmc2: running CQE recovery
[  370.660399] mmc2: running CQE recovery
[  370.662973] I/O error, dev mmcblk2, sector 12891160 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
[  370.668034] mmc2: running CQE recovery
[  370.675353] mmc2: running CQE recovery
[  370.677244] I/O error, dev mmcblk2, sector 12886040 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 0
[  370.681954] mmc2: running CQE recovery
[  370.691242] mmc2: running CQE recovery
[  370.697018] mmc2: running CQE recovery
[  370.698975] I/O error, dev mmcblk2, sector 12887064 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 0
[  370.703727] mmc2: running CQE recovery
..........

 

This can lead to unexpected behaviour, when using sata-nand-installer e.g., because partition can be mounted but doesn't work as expected.

 

I suggest to disable hs400 for now, this will fallback to hs200.

Cold boot prints no errors, while reboots have some lines 

mmc2: mmc_select_hs200 failed, error -110
mmc2: error -110 whilst initialising MMC card
but gets the job done.
 

 

board-nanopct4-disable-hs400.patch

[balbes150]

06.03.2022 в 20:38, Viper сказал:

since latest upgrade to new kernel 22.02 stable the system becomes unstable. There are issues writing to mmc2 and "EXT4-fs (mmcblk2p1): Remounting filesystem read-only". This does not allow most of the apps to work properly (e.g. openmediavault stops working)

I tried to switch back to previous kernel version through armbian-config but that does not work too

Can you check the last one and show the result using the versions from here ?

 

https://disk.yandex.ru/d/_CAf6mgtVDGS4A

[fraz0815]

I tested Armbian_22.02.0-trunk_Nanopct4_bullseye_edge_5.16.8.img, same errors on media kernel for me:

http://ix.io/3SjQ

 

[  656.511836] ------------[ cut here ]------------
[  656.511851] mmc2: cqhci: spurious TCN for tag 7
[  656.511959] WARNING: CPU: 0 PID: 6 at drivers/mmc/host/cqhci-core.c:786 cqhci_irq+0x504/0x670
[  656.511988] Modules linked in: crct10dif_ce snd_soc_spdif_tx gpio_ir_recv rc_core snd_soc_simple_card snd_soc_simple_card_utils panfrost pwm_fan hantro_vpu(C) gpu_sched hci_uart rockchip_vdec(C) rockchip_rga btqca rockchip_iep v4l2_h264 videobuf2_dma_sg videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_contig snd_soc_rockchip_i2s btrtl videobuf2_memops btbcm btsdio btintel videobuf2_v4l2 bluetooth videobuf2_common fusb302 tcpm brcmfmac videodev typec snd_soc_rt5651 ecdh_generic brcmutil ecc cfg80211 rfkill mc zram sunrpc fuse adc_keys
[  656.512272] CPU: 0 PID: 6 Comm: kworker/0:0H Tainted: G         C        5.16.8-media #trunk
[  656.512289] Hardware name: FriendlyElec NanoPC-T4 (DT)
[  656.512298] Workqueue: kblockd blk_mq_run_work_fn
[  656.512324] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  656.512340] pc : cqhci_irq+0x504/0x670
[  656.512353] lr : cqhci_irq+0x504/0x670
[  656.512365] sp : ffff800008003d90
[  656.512373] x29: ffff800008003d90 x28: 0000000000004000 x27: ffff800009a91000
[  656.512399] x26: ffff00000063c580 x25: ffff00000070fa98 x24: ffff800009846fb8
[  656.512425] x23: ffff80000a14cf00 x22: 0000000000000002 x21: ffff00000063c000
[  656.512451] x20: ffff00000070fa80 x19: 0000000000000007 x18: 0000000000000020
[  656.512476] x17: ffff8000edc74000 x16: ffff800008004000 x15: ffffffffffffffff
[  656.512502] x14: 0000000000000000 x13: 0000000000000328 x12: ffff800008003aa0
[  656.512527] x11: ffff800009f1f458 x10: 00000000ffffe000 x9 : ffff800009f1f458
[  656.512553] x8 : ffff800009e6f458 x7 : ffff800009f1f458 x6 : 0000000000000000
[  656.512578] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000027
[  656.512602] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000685a00
[  656.512627] Call trace:
[  656.512636]  cqhci_irq+0x504/0x670
[  656.512649]  sdhci_arasan_cqhci_irq+0x54/0x84
[  656.512669]  sdhci_irq+0xc4/0xf30
[  656.512682]  __handle_irq_event_percpu+0x60/0x250
[  656.512704]  handle_irq_event+0x64/0x150
[  656.512722]  handle_fasteoi_irq+0xc0/0x1bc
[  656.512738]  generic_handle_domain_irq+0x3c/0x60
[  656.512756]  gic_handle_irq+0xd8/0x2c4
[  656.512776]  call_on_irq_stack+0x2c/0x38
[  656.512793]  do_interrupt_handler+0xd4/0xe0
[  656.512809]  el1_interrupt+0x48/0xf0
[  656.512826]  el1h_64_irq_handler+0x18/0x24
[  656.512842]  el1h_64_irq+0x78/0x7c
[  656.512856]  preempt_count_sub+0x4c/0xe0
[  656.512874]  sdhci_cqe_enable+0x12c/0x2a0
[  656.512892]  sdhci_arasan_cqe_enable+0xa4/0xf0
[  656.512911]  cqhci_request+0xd4/0x680
[  656.512923]  mmc_cqe_start_req+0xb4/0x1a0
[  656.512940]  mmc_blk_mq_issue_rq+0x4d0/0xa60
[  656.512954]  mmc_mq_queue_rq+0x118/0x2ac
[  656.512968]  blk_mq_dispatch_rq_list+0x198/0x824
[  656.512987]  __blk_mq_sched_dispatch_requests+0xb4/0x170
[  656.513004]  blk_mq_sched_dispatch_requests+0x3c/0x80
[  656.513019]  __blk_mq_run_hw_queue+0x54/0x90
[  656.513035]  blk_mq_run_work_fn+0x24/0x30
[  656.513051]  process_one_work+0x1fc/0x4b0
[  656.513071]  worker_thread+0x13c/0x470
[  656.513088]  kthread+0x164/0x180
[  656.513104]  ret_from_fork+0x10/0x20
[  656.513120] ---[ end trace 7498d4113b84f613 ]---

 

[Ogy]

On Nanopc M4v2 not even boot from emmc, bionic/buster legacy latest update from 2-3 days ago (probably 22.02..).

Edited March 21, 2022 by Ogy

[balbes150]

I checked this information, yes there is a problem on T4. A PR with the proposed correction will be sent in the near future.

 

As a temporary solution for already downloaded 5.16 kernel images, you can replace DTB with a new one.

 

 

rk3399-nanopc-t4.dtb

[balbes150]

The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card.

[fraz0815]

Am 24.3.2022 um 13:25 schrieb balbes150:

The test version of ArmbianTV 20220324 with a new version of u-boot-2022. Allows you to select different systems when starting on the TV screen from the keyboard. This will allow you to have several different systems on eMMC at once and choose which system to run. Please note, this is a test version and there may be errors in it. I recommend checking its operation by launching it from an SD card.

 

Multiboot sounds great. Could we use this feature even when running headless? Maybe with a simple file, which tells uboot what to boot.

[balbes150]

42 минуты назад, fraz0815 сказал:

Multiboot sounds great. Could we use this feature even when running headless? Maybe with a simple file, which tells uboot what to boot.

This has been possible for a long time (available in all versions of Armbian that switched to using extlinux.conf), but requires manual editing of extlinux.conf (changing the parameter that is responsible for loading by default it is enough to change one line).

Please note, extlinux.conf is a standard settings file that is well documented in u-boot. In fact, it is very close to the logic of using grub.cfg

[balbes150]

New version 20220331-edge with kernel 5.16.18.

Important. Now u-boot-2022 is used with the enabled function of displaying the system (kernel) selection menu immediately at the startup stage. This allows you to have multiple systems (cores) on the media and select them from the keyboard immediately when the system starts.

[prahal]

@fraz0815 

Could you try to revert those kernel commits :

06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66

and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related).

 

  see

 

 

Those commits are proper fixes but trigger the emmc hs400 breakage on helios64 rockchip 3399 .

[fraz0815]

Thank you, I will try reverting and report back.

Just disabling hs400 is not perfect, since it breaks reboot now, but works fine after shutdown/power disconnect.

I tried some sdhci.debug_quirks(2), but they did not help so far.

 

[fraz0815]

@prahal 

That worked indeed, thanks!

Emmc is working perfectly fine for me (reboot, poweroff etc), even in hs400-es mode. 

Does this patch break any other boards? I am afraid it might does, so it sounds like a bad idea to make a PR for all rk3399 boards.

Any suggestions are welcome, guess I have to look how Helios64 handles this.

 

:edit 
What I did:
 

I removed rk3399-nanopc-t4-emmc.patch, so re-enabling hs400
 

--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -109,10 +109,10 @@
 	};
 };
 
-&sdhci {
-	mmc-hs400-1_8v;
-	mmc-hs400-enhanced-strobe;
-};
+//&sdhci {
+//	mmc-hs400-1_8v;
+//	mmc-hs400-enhanced-strobe;
+//};
 
 &u2phy0_host {
 	phy-supply = <&vcc5v0_host0>;

 

and reverted both commits you mentioned.
 

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d9540a845..0e3192e55 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1525,12 +1525,7 @@ static int set_machine_constraints(struct regulator_dev *rdev)
 	 * and we have control then make sure it is enabled.
 	 */
 	if (rdev->constraints->always_on || rdev->constraints->boot_on) {
-		/* If we want to enable this regulator, make sure that we know
-		 * the supplying regulator.
-		 */
-		if (rdev->supply_name && !rdev->supply)
-			return -EPROBE_DEFER;
-
+		
 		if (rdev->supply) {
 			ret = regulator_enable(rdev->supply);
 			if (ret < 0) {
@@ -5470,24 +5465,11 @@ regulator_register(const struct regulator_desc *regulator_desc,
 	else if (regulator_desc->supply_name)
 		rdev->supply_name = regulator_desc->supply_name;
 
+	if (regulator_resolve_supply(rdev))
+	        rdev_dbg(rdev, "unable to resolve supply\n");
+	
 	ret = set_machine_constraints(rdev);
-	if (ret == -EPROBE_DEFER) {
-		/* Regulator might be in bypass mode and so needs its supply
-		 * to set the constraints
-		 */
-		/* FIXME: this currently triggers a chicken-and-egg problem
-		 * when creating -SUPPLY symlink in sysfs to a regulator
-		 * that is just being created
-		 */
-		rdev_dbg(rdev, "will resolve supply early: %s\n",
-			 rdev->supply_name);
-		ret = regulator_resolve_supply(rdev);
-		if (!ret)
-			ret = set_machine_constraints(rdev);
-		else
-			rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
-				 ERR_PTR(ret));
-	}
+	
 	if (ret < 0)
 		goto wash;
 

 

[ScottP]

I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. 

EMMC went readonly, I assume due to errors. There was no Networking, ethernet and wifi not present. NVME not working either. I could not easily get an ambianmonitor due to my storage being read only or missing and no networking. 

I resolved the issue by attaching serial console, booting from my install sd, fsck my emmc, mount it and copy over the 5.10.63 boot files and modules. I then froze kernel.

ambian-config is only offering legacy kernels now

I probably need to downgrade via apt so that the running kernel reflects what apt says I have.

I cant do testing as this board is in production. 

I will watch this and other threads  so determine what and when to upgrade kernel

 

[Viper]

3 hours ago, ScottP said:

I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. 

EMMC went readonly, I assume due to errors. There was no Networking, ethernet and wifi not present. NVME not working either. I could not easily get an ambianmonitor due to my storage being read only or missing and no networking. 

I resolved the issue by attaching serial console, booting from my install sd, fsck my emmc, mount it and copy over the 5.10.63 boot files and modules. I then froze kernel.

ambian-config is only offering legacy kernels now

I probably need to downgrade via apt so that the running kernel reflects what apt says I have.

I cant do testing as this board is in production. 

I will watch this and other threads  so determine what and when to upgrade kernel

 

I did the same ..with exactly the same result, however downloading and installing the latest Bullseye image it works. Latest image contains 5.17.9.

It includes a patch to reduce speed in accessing eMMC, that is the root issue (it moves from HS400  to HS200)

[balbes150]

4 часа назад, ScottP сказал:

I did apt upgrade today on my nanoPC T4 and kernel updated from 5.10.63 to 5.15.35. 

What exactly is the version of the image and where (eMMC\NVMe etc) do you have installed?

[Viper]

1 hour ago, balbes150 said:

What exactly is the version of the image and where (eMMC\NVMe etc) do you have installed?

https://redirect.armbian.com/region/NA/nanopct4/Bullseye_current

Bullseye 5.17.x (.9 actually)

[Viper]

Just now, Viper said:

https://redirect.armbian.com/region/NA/nanopct4/Bullseye_current

Bullseye 5.17.x (.9 actually)

I have the standard eMMC which comes with Nanopc T4. I do not know the exact chipset.

[ScottP]

@balbes My system was originally installed with armbian 21.08.03 bullseye, updated infrequently. The last upgrade took it to Armbian 22.05.1 and the kernel version  to 5.15.35. 

I have standard EMMC that the nanopc T4 comes with soldered to the board. My NVME drive is a samsung one that had been working fine for many months until this update.

I can see that the current mainline images for download all contain either 5.17.* or 5.18.* and as @Viper says 5.17.9 does not exhibit the problem. So I will install 5.17.* or 5.18.*  at some point

Maybe 5.15.* should be removed from the repo for rockchip64:

ii  linux-image-current-rockchip64    22.05.1                        arm64        Linux kernel, armbian version 5.15.35-rockchip64 current

and the 5.17.* ones not marked as bleeding edge any more, since they are included in the latest supported downloads.

 

edit: I installed 5.18.3 and NVME not found, EMMC is readonly and no networking - the same as 5.15.35. I will try to install 5.17.* but armbian-config is not showing it as an option.

edit2: 5.16.11 - same issues as 5.18.3 and 5.15.35. armbian-config is not showing  5.17.* as an option to install. I will try booting an image instead.

Eventually got 5.17.9 kernel which works without the above issues. Copied over files manually, extlinux.conf contains root uuid so that needs editing if installing

Edited June 13, 2022 by ScottP
Updated

[prahal]

On 4/11/2022 at 6:52 PM, fraz0815 said:

Emmc is working perfectly fine for me (reboot, poweroff etc), even in hs400-es mode. 

Does this patch break any other boards? I am afraid it might does, so it sounds like a bad idea to make a PR for all rk3399 boards.

This code should be fine for all boards, this is the way the code was doing before v5.10.44. Though the developers patch upon the code that made this regression (code which looks fine on the paper but in practice breaks hs400es on rk3399 at least).

 

I though that 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init") would also fix rk3399 emmc CQHCI but it did not.

[prahal]

Good news. Without the revert and on Armbian v6.11 with a few  v6.12 patches for drivers/regulator/core.c  (that are in stable/master) I can mount my EMMC partition on my rk3399 with hs400es enabled without getting the cqhci error (not tested extensively but at least an improvement.

I applied above Armbian edge v6.11:

 

cb3543cff90a regulator: core: fix deadlock on regulator enable
0debed5b117d regulator: core: Fix resolve supply lookup issue
8f3cbcd6b440 regulator: core: Use different devices for resource allocation and DT lookup
ba62319a42c5 regulator: core: fix resource leak in regulator_register()
da46ee19cbd8 regulator: core: fix module refcount leak in set_supply()
0591b14ce039 regulator: core: fix use_count leakage when handling boot-on
dc8d006d15b6 regulator: core: use kfree_const() to free space conditionally
f2b41b748c19 regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()
fd1845069711 regulator: devres: Add devm_regulator_bulk_get_exclusive()

 

Likely the fix would be 0debed5b117d regulator: core: Fix resolve supply lookup issue though that needs testing.

[prahal]

This was not fixed. Testing thoroughly on 6.3 the write path I can reproduce the cqhci errors.

I don't understand why commits

06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66

and aea6cb99703e17019e025aa71643b4d3e0a24413 broke hs400 support on rk3399 (but as anybody disabled hs400 on rk339 at least nobody notice anymore).

[RussianNeuroMancer]

On 7/8/2023 at 6:08 AM, prahal said:

but as anybody disabled hs400 on rk339 at least nobody notice anymore

What do you mean? hs400 is still there.

[prahal]

On 10/19/2023 at 1:13 AM, RussianNeuroMancer said:

On 7/8/2023 at 6:08 AM, prahal said:

but as anybody disabled hs400 on rk339 at least nobody notice anymore

What do you mean? hs400 is still there.

 

I did not check every board file. But most did remove it explaining it was not working. It could be nobody run the rk339-nanpc-t4 dts from mainline so nobody disabled it.

 

I you have such a board and can write to emmc with hs400 enabled that would help a lot. But I doubt it would work on nanopc-t4 while I saw tenths of boards.

in 2023 so pretty late after the issue arised (maybe 2 years)

Rock 4C+ https://github.com/torvalds/linux/commit/2bd1d2dd808c60532283e9cf05110bf1bf2f9079

Rock Pi 4 https://github.com/torvalds/linux/commit/cee572756aa2cb46e959e9797ad4b730b78a050b

 

and all armbian rk3399 boards have it disabled as far as I know.

 

by the way, thanks for the challenge to prove my point 🙂 . I found this

https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4

and this

https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e phy: rockchip: set pulldown for strobe line in dts

which might be related to this emmc issue (as noted in the mainline patch in the rockchip kernel this emmc pulldown setting is always enabled while in mainline it is disabled by default).

 

This patch introduced in 5.11 might explain why even with the regulator issue fixed (the one I found by regression testing) with newer kernel I still had hs400 failing on me.

 

Edit: indeed with this emmc_phy pulldown setting in the dts I can now write to the emmc in hs400es mode !

Thanks a lot for pointing out that nanopc-t4 was working with hs400es!

 

The thing is they never posted a message binding the CQE error messages to their fix.. they tell it fixes a write error.

And knowing how many hs400 broken leftover there was - including the two above commit from 2023 - this was pretty hard to guess they had a fix for their board dts.

 

I believe the rationale is the same as for rk3588 "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 "

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.

except for rk3588 they decided to do the opposite, that is set the pulldown for all and let specific boards disabled it.

 

So to fix hs400es on rk3399 add under the emmc_phy node on most (if not all) boards dts:

    rockchip,enable-strobe-pulldown;

 

 

Edited December 15, 2023 by prahal