• State Resolved
  • Replies 14 replies
  • Subscribers 103 subscribers
  • Views 417 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

AM62L-PROCESSOR-SDK: AM62L:Regarding mmc0 Timeout print

AM62L-PROCESSOR-SDK: random eMMC panics

Dominik Haller
Prodigy 160 points
Part Number: AM62L-PROCESSOR-SDK
Other Parts Discussed in Thread: AM62L

Tool/software:

Hi,

this is a follow up to  RE: AM62L-PROCESSOR-SDK: AM62L:Regarding mmc0 Timeout print 

We still see those issues once in ~250 boots on our AM62L SR1.0 hardware.

This is a log using the most recent kernel/u-boot/tf-a/firmware with tag 11.01.16 from TI:

[    1.633563] mmc0: CQHCI version 5.10^M
[    1.633994] mmc1: CQHCI version 5.10^M
[    1.646319] [drm] Initialized tidss 1.0.0 for 30200000.dss on minor 0^M
[    1.675640] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit^M
[    1.683090] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit^M
[    1.716208] mmc1: new high speed SDHC card at address 59b4^M
[    1.717465] mmcblk1: mmc1:59b4 USDU1 28.3 GiB^M
[    1.717930] Console: switching to colour frame buffer device 160x50^M
[    1.720691]  mmcblk1: p1 p2^M
[    1.768014] tidss 30200000.dss: [drm] fb0: tidssdrmfb frame buffer device^M
[    1.776334] clk: Disabling unused clocks^M
[    1.784792] PM: genpd: Disabling unused power domains^M
[    1.790014] ALSA device list:^M
[    1.793138]   No soundcards found.^M
[    1.827149] usb 1-1: new high-speed USB device number 2 using xhci-hcd^M
[    1.834004] mmc0: Got data interrupt 0x00600000 even though no data operation was in progress.^M
[    1.842612] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========^M
[    1.849036] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001004^M
[    1.855460] mmc0: sdhci: Blk size:  0x00007080 | Blk cnt:  0x00000001^M
[    1.861884] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013^M
[    1.868308] mmc0: sdhci: Present:   0x01ff00f0 | Host ctl: 0x0000003d^M
[    1.874736] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080^M
[    1.881160] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007^M
[    1.887585] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000^M
[    1.894009] mmc0: sdhci: Int enab:  0x03ff000b | Sig enab: 0x03ff000b^M
[    1.900433] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000^M
[    1.906857] mmc0: sdhci: Caps:      0x7decc801 | Caps_1:   0x18002407^M
[    1.913281] mmc0: sdhci: Cmd:       0x0000153a | Max curr: 0x00000000^M
[    1.919705] mmc0: sdhci: Resp[0]:   0x00000800 | Resp[1]:  0xffffffff^M
[    1.926133] mmc0: sdhci: Resp[2]:   0x328f5903 | Resp[3]:  0x00d00f00^M
[    1.932557] mmc0: sdhci: Host ctl2: 0x00000003^M
[    1.936988] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000847ab200^M
[    1.944106] mmc0: sdhci: ============================================^M
[    1.951187] usb 2-1: new high-speed USB device number 2 using xhci-hcd^M
[    1.962870] mmc0: Command Queue Engine enabled^M
[    1.967427] mmc0: new HS200 MMC card at address 0001^M
[    1.973348] mmcblk0: mmc0:0001 DG4016 14.7 GiB^M
[    1.979712]  mmcblk0: p1 p2^M
[    1.983563] mmcblk0boot0: mmc0:0001 DG4016 4.00 MiB^M
[    1.989912] mmcblk0boot1: mmc0:0001 DG4016 4.00 MiB^M
[    1.996376] mmcblk0rpmb: mmc0:0001 DG4016 4.00 MiB, chardev (239:0)^M
[    2.047966] EXT4-fs (mmcblk1p2): recovery complete^M
[    2.056602] EXT4-fs (mmcblk1p2): mounted filesystem eac08a2d-ff82-4864-b571-fe91c6e16a09 r/w with ordered data mode. Quota mode: none.^M
[    2.068805] VFS: Mounted root (ext4 filesystem) on device 179:2.^M
[    2.076020] devtmpfs: mounted^M

https://gist.github.com/dominiknh90/9d17277978c5c33e65f8e0d3ebf3d504

We have no functional issues with the eMMC and all signals are within JEDEC spec.

The original ticket got closed without conclusion and the question remained unanswered.

Has there been any updates regarding this?

Best regards

Dominik

  • 0
    TI__Guru 73881 points

    Hello,

    Dominik Haller said:
    We have no functional issues with the eMMC and all signals are within JEDEC spec.

    Is your schematics reviewed by TI?

  • 0 in reply to Prashant Shivhare
    Prodigy 160 points

    Hi Prashant,

    yes TI did a review of our SoM schematics.

  • 0
    Prodigy 160 points

    Some updates:

    We found some patterns in binaries that reliably cause trouble with our hardware (eMMC: SDINBDG4-8G-I2 8GB and 16GB variant):

    0000000 002f 0080 0080 0080 00d3 00ff 00d7 0074
0000010 0080 00ff 00ff 00d4 0079 0001 0080 0080
0000020 00d6 00d4 00fd 00ec 0080 0080 00ff 00ff
0000030 00d5 0054 008d 0080 00ff 00ca 00c9 00fc
0000040 0080 0080 0080 00db 00f0 00a0 0050 002a
0000050 00cd 00ff 00b9 00a2 0001 0080 0080 0080
0000060 0080 0080 00ff 0001 0080 0080 0080 0080
0000070 0001 00f4 0080 0080 0080 0080 0080 00ff
0000080 0080 0080 0080 0080 00ff 0001 00ee 0080
0000090 0080 0080 0080 0080 0080 0080 0080 0080
00000a0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00000e0 00ff 00f6 00b0 00ff 00ff 00ff 00ff 00ff
00000f0 00ff 00ff 00ff 00ff 00ff 00fc 00f1 00df
0000100 00ff 00ff 00ff 00ff 00f9 00ff 00ff 00ff
0000110 00ff 00ff 00fd 00fd 00ff 00ff 00ff 00ff
0000120 00f4 00ff 00ff 00ff 00ff 00ff 00ff 00fc
0000130 00ff 00ff 00ff 00ff 00fe 00fe 00ea 00ff
0000140 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
0000150 00ff 00ff 00ff 00fd 00ff 00ff 00ff 00ff
0000160 00ff 00ff 00ff 00ff 00ff 00ff 00fe 00f6
0000170 00ff 00ff 00ff 00ff 00fd 00ef 00ff 00ff
0000180 00ff 00ff 00ff 00fe 00ff 00ff 00ff 00ff
0000190 00fe 00ff 00fe 00ff 00ff 00ff 00ff 00ff
00001a0 00ff 00ff 00ff 00ff 00ff 00fe 00f8 00ff
00001b0 00ff 00ff 00ff 00ff 00fb 00ff 00ff 00ff
00001c0 00ff 00ff 00fe 00ff 00ff 00ff 00ff 00ff
00001d0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
00001e0 00ff 00ff 00ff 00ff 00fe 00fd 00ff 00ff
00001f0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
0000200 00ff 00fe 00fe 00fb 00ff 00ff 00ff 00ff
0000210 00fe 00ff 00ff 00ff 00ff 00ff 00fe 00ff
0000220 00ff 00ff 00ff 00ff 00fe 00ff 00ff 00ff
0000230 00ff 00fe 00ff 00fd 00ff 00ff 00ff 00ff
0000240 00fe 00ff 00fa 00ff 00ff 00ff 00fe 00ff
0000250 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00fe
0000260 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00002b0 00ff 00ff 00ff 00d9 00ff 00ff 00ff 00ff
00002c0 00e1 00ff 00ff 00ff 00ff 00fd 00f1 00fc
00002d0 00ff 00ff 00fe 00ff 00fa 00ea 00ff 00ff
00002e0 00ff 00fd 00fa 00f1 00ff 00ff 00fe 00fd
00002f0 00ff 00fe 00ff 00ff 00ff 00ff 00ff 00ff
0000300 00ff 00ff 00ff 00ff 00ff 00fe 00fe 00df
0000310 00ff 00ff 00ff 00ff 00ee 00ff 00ff 00ff
0000320 00ff 00fe 00fe 00fd 00ff 00ff 00ff 00ff
0000330 00f8 00ff 00ff 00ff 00ff 00ff 00ff 00fe
0000340 00ff 00ff 00ff 00ff 00ff 00fe 00f9 00ff
0000350 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
0000370 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00fd
0000380 00ff 00ff 00ff 00ff 00fe 00f7 00ff 00ff
0000390 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00003b0 00ff 00ff 00ff 00ff 00ff 00fe 00fd 00ff
00003c0 00ff 00ff 00ff 00ff 00fc 00ff 00ff 00ff
00003d0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00003f0 00ff 00ff 00ff 00ff 00fe 00fe 00ff 00ff
0000400 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
0000410 00ff 00ff 00ff 00fd 00ff 00ff 00ff 00ff
0000420 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
0000430 00ff 00ff 00ff 00ff 00fe 00ff 00ff 00ff
0000440 00ff 00ff 00ff 00fd 00ff 00ff 00ff 00ff
0000450 00ff 00ff 00fa 00ff 00ff 00ff 00ff 00ff
0000460 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00fe
0000470 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00004c0 00ff 00fa 00fb 00ba 00ff 00ff 00ff 00ff
00004d0 00ea 00ff 00ff 00ff 00ff 00fe 00f4 00fb
00004e0 00ff 00ff 00ff 00ff 00fb 00fb 00ff 00ff
00004f0 00ff 00fe 00fd 00f3 00ff 00ff 00ff 00fe
0000500 00fe 00fd 00ff 00ff 00ff 00ff 00ff 00ff
0000510 00ff 00ff 00ff 00ff 00ff 00fe 00fd 00ec
0000520 00ff 00ff 00ff 00ff 00fb 00ff 00ff 00ff
0000530 00fe 00fe 00fd 00fd 00ff 00ff 00ff 00ff
0000540 00fe 00ff 00ff 00ff 00ff 00ff 00ff 00fe
0000550 00ff 00ff 00ff 00ff 00fe 00fe 00fe 00ff
0000560 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
0000580 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00fe
0000590 00ff 00ff 00ff 00ff 00fe 00fe 00ff 00ff
00005a0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
00005b0 00ff 00ff 00fe 00ff 00ff 00ff 00ff 00ff
00005c0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
00005d0 00ff 00ff 00ff 00ff 00fe 00ff 00ff 00ff
00005e0 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
*
00006d0 00ff 00ff 00ff 00f8 00ff 00ff 00ff 00ff
00006e0 00fa 00ff 00ff 00ff 00ff 00fe 00fc 00fe
00006f0 00ff 00ff 00ff 00ff 00fe 00f8 00ff 00ff
0000700 00ff 00ff 00fd 00f9 00ff 00ff 00ff 00ff
0000710 00fd 00fd 00ff 00ff 00ff 00ff 00ff 00ff
0000720 00ff 00ff 00ff 00ff 00ff 00fd 00fd 00f6
0000730 00ff 00ff 00ff 00ff 00fc 00ff 00ff 00ff
0000740 00fe 00fe 00fb 00fe 00ff 00ff 00ff 00ff
0000750 00fe 00ff 00ff 00ff 00ff 00ff 00ff 00fc
0000760 00ff 00ff 00ff 00ff 00fd 00fe 00f8 00ff
0000770 00ff 00ff 00ff 00ff 00ff 00ff 00ff 00ff
0000780 00fe 00fe 00ff 00fd 00ff 00ff 00ff 00ff
0000790 00ff 00ff 00ff 00ff 00ff 00ff 00fe 00fb
00007a0 00ff 00ff 00ff 00ff 00fb 00f5 00ff 00ff
00007b0 00ff 00ff 00ff 00fe 00ff 00ff 00ff 00ff
00007c0 00fe 00fd 00fd 00ff 00ff 00ff 00ff 00ff
00007d0 00ff 00ff 00ff 00ff 00ff 00fd 00fb 00ff
00007e0 00ff 00ff 00ff 00ff 00fc 00ff 00ff 00ff
00007f0 00ff 00ff 00fe 00fd 00ff 00ff 00ff 00ff
0000800

    Error log (with latest TI tag 11.02.02):

    [  317.172532] mmc0: running CQE recovery
[  317.276504] mmc0: running CQE recovery
[  317.291809] mmc0: running CQE recovery
[  317.438035] mmc0: running CQE recovery
[  317.490796] mmc0: running CQE recovery
[  317.499727] mmc0: running CQE recovery
[  317.524636] mmc0: running CQE recovery
[  317.534828] I/O error, dev mmcblk0, sector 23743488 op 0x1:(WRITE) flags 0x4000 phys_seg 9 prio class 2
[  317.547913] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 15141 starting block 2968960)
[  317.565366] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss!  (inode 15141, error -5)
[  317.577822] Buffer I/O error on device mmcblk0p2, logical block 2932736
[  317.584641] Buffer I/O error on device mmcblk0p2, logical block 2932737
[  317.591383] Buffer I/O error on device mmcblk0p2, logical block 2932738
[  317.598174] Buffer I/O error on device mmcblk0p2, logical block 2932739
[  317.602291] mmc0: running CQE recovery
[  317.606718] Buffer I/O error on device mmcblk0p2, logical block 2932740
[  317.618133] Buffer I/O error on device mmcblk0p2, logical block 2932741
[  317.620850] I/O error, dev mmcblk0, sector 23781376 op 0x1:(WRITE) flags 0x4000 phys_seg 17 prio class 2
[  317.624924] Buffer I/O error on device mmcblk0p2, logical block 2932742
[  317.641112] Buffer I/O error on device mmcblk0p2, logical block 2932743
[  317.647868] Buffer I/O error on device mmcblk0p2, logical block 2932744
[  317.654305] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 15141 starting block 2972800)
[  317.654636] Buffer I/O error on device mmcblk0p2, logical block 2932745
[  317.695367] mmc0: running CQE recovery
[  317.703600] I/O error, dev mmcblk0, sector 23782488 op 0x1:(WRITE) flags 0x4000 phys_seg 47 prio class 2
[  317.728693] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 15141 starting block 2973579)
[  317.740441] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss!  (inode 15141, error -5)
[  323.548155] mmc0: running CQE recovery
[  323.662710] mmc0: running CQE recovery
[  323.760734] mmc0: running CQE recovery

    With command queue disabled (sdhci.debug_quirks=0x65168080) the issues can be seen too:

    [  151.926679] I/O error, dev mmcblk0, sector 14584832 op 0x1:(WRITE) flags 0x4000 phys_seg 69 prio class 2
[  151.936300] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 15085 starting block 1823488)
[  152.010997] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss!  (inode 15085, error -5)
[  152.026374] Buffer I/O error on device mmcblk0p2, logical block 1787904
[  152.033406] Buffer I/O error on device mmcblk0p2, logical block 1787905
[  152.040297] Buffer I/O error on device mmcblk0p2, logical block 1787906
[  152.047306] Buffer I/O error on device mmcblk0p2, logical block 1787907
[  152.054141] Buffer I/O error on device mmcblk0p2, logical block 1787908
[  152.061022] Buffer I/O error on device mmcblk0p2, logical block 1787909
[  152.067877] Buffer I/O error on device mmcblk0p2, logical block 1787910
[  152.075054] Buffer I/O error on device mmcblk0p2, logical block 1787911
[  152.082151] Buffer I/O error on device mmcblk0p2, logical block 1787912
[  152.089195] Buffer I/O error on device mmcblk0p2, logical block 1787913
[  152.254226] I/O error, dev mmcblk0, sector 14622720 op 0x1:(WRITE) flags 0x4000 phys_seg 10 prio class 2
[  152.256193] I/O error, dev mmcblk0, sector 14623744 op 0x1:(WRITE) flags 0x4000 phys_seg 10 prio class 2
[  152.310151] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 15085 starting block 1828736)
[  152.321725] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss!  (inode 15085, error -5)
[  153.655212] I/O error, dev mmcblk0, sector 14308352 op 0x1:(WRITE) flags 0x4000 phys_seg 14 prio class 2

    Speed modes slower than HS200 don't show the issues.

    Interestingly we don't see any issues with the usual mmc stress tools and random number based binaries. Even tests at -40°C or +75°C don't show any issues. But binaries with patterns like above (we found it while flashing the Armbian image) will cause issues immediately.

    We're wondering if it's some software bug or if it could be related to i2493 MMCSD: HS200 write failures.

  • +1 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    The issue is likely caused by i2493.

    Please apply the kernel patch attached below, the "running CQE recovery" messages will still happen, but the patch will ensure the data written to eMMC are not corrupted.

    Fullscreen 0001-mmc-use-single-block-write-when-CQE-recovery-happene.diff Download 
    diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index 5463697a8442..d4825cd3c7b7 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -258,6 +258,7 @@ static const char *const rqf_name[] = {
 	RQF_NAME(ZONE_WRITE_PLUGGING),
 	RQF_NAME(TIMED_OUT),
 	RQF_NAME(RESV),
+	RQF_NAME(XFER_SINGLE_BLK),
 };
 #undef RQF_NAME
 
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 1d08009f2bd8..0367808e3882 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1440,6 +1440,9 @@ static void mmc_blk_data_prep(struct mmc_queue *mq, struct mmc_queue_req *mqrq,
 		    rq_data_dir(req) == WRITE &&
 		    (md->flags & MMC_BLK_REL_WR);
 
+	if (req->rq_flags & RQF_XFER_SINGLE_BLK)
+		recovery_mode = 1;
+
 	memset(brq, 0, sizeof(struct mmc_blk_request));
 
 	mmc_crypto_prepare_req(mqrq);
@@ -1579,10 +1582,13 @@ static void mmc_blk_cqe_complete_rq(struct mmc_queue *mq, struct request *req)
 		err = 0;
 
 	if (err) {
-		if (mqrq->retries++ < MMC_CQE_RETRIES)
+		if (mqrq->retries++ < MMC_CQE_RETRIES) {
+			if (rq_data_dir(req) == WRITE)
+				req->rq_flags |= RQF_XFER_SINGLE_BLK;
 			blk_mq_requeue_request(req, true);
-		else
+		} else {
 			blk_mq_end_request(req, BLK_STS_IOERR);
+		}
 	} else if (mrq->data) {
 		if (blk_update_request(req, BLK_STS_OK, mrq->data->bytes_xfered))
 			blk_mq_requeue_request(req, true);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 959f8f82a650..9b45e9451059 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -61,6 +61,7 @@ enum {
 	/* ->timeout has been called, don't expire again */
 	__RQF_TIMED_OUT,
 	__RQF_RESV,
+	__RQF_XFER_SINGLE_BLK,
 	__RQF_BITS
 };
 
@@ -82,6 +83,8 @@ enum {
 			((__force req_flags_t)(1 << __RQF_ZONE_WRITE_PLUGGING))
 #define RQF_TIMED_OUT		((__force req_flags_t)(1 << __RQF_TIMED_OUT))
 #define RQF_RESV		((__force req_flags_t)(1 << __RQF_RESV))
+#define RQF_XFER_SINGLE_BLK	\
+			((__force req_flags_t)(1 << __RQF_XFER_SINGLE_BLK))
 
 /* flags that prevent us from merging requests: */
 #define RQF_NOMERGE_FLAGS \
-- 
2.34.1

  • 0 in reply to Bin Liu
    Prodigy 160 points

    Hi  

    I applied your patch and can confirm it works on our side.

    A few follow up questions:

    1) Are you going to add this quirk to the TI kernel/SDK by default?

    2) Is there anything else that can be done in software or is the only workaround for i2493 to be extra careful with hardware layout?

    Thanks

    Dominik

  • 0 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    Glad to hear the patch can solve the problem.

    I have provided the patch to our sw dev team as a proposed implementation of the sw workaround mentioned in i2493. It is up to the dev team and the kernel upstream acceptance for the final implementation in the SDK kernel.

    Other than the hardware/board design consideration in i2493, this patch should be the only sw change needed on top of the current SDK kernel (6.12.y).

  • 0 in reply to Bin Liu
    Prodigy 160 points

    Hi Bin,

    just fyi we were not able to reproduce the issue on the AM62L EVM.

    I though of using DDR52 speed mode as fallback in case we won't be able to fix the problems in hardware.

    Do you see any issues using that mode with AM62L as it is not enabled in the devicetree by default?

    Thanks

    Dominik

  • 0 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    I don't see DDR52 is listed in the AM62L Datasheet eMMC Interface section.

    If you cannot fix it in hardware, I think there is another sw workaround - to reduce the eMMC bus clock from 200MHz by reducing the eMMC controller refclk. If you don't know how to change it, I will try to take a look in the next few days.

  • 0 in reply to Bin Liu
    Prodigy 160 points

    Hi Bin,

    root@am62lxx-libra-fpsc-1:~# cat /sys/kernel/debug/mmc0/ios 
clock:        52000000 Hz
actual clock:    50000000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:    2 (push-pull)
chip select:    0 (don't care)
power mode:    2 (on)
bus width:    3 (8 bits)
timing spec:    8 (mmc DDR52)
signal voltage:    1 (1.80 V)
driver type:    0 (driver type B)

    I think DDR52 is just what Linux calls it. in the JEDEC spec and the AM62L TRM it's called "High Speed DDR":

  • 0 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    The following devicetree patch should disable eMMC HS200 mode, and make it only running at HS DDR mode.

    diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
index 3d12a9fa30b5..c5c3f6ebf94e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
@@ -645,6 +645,7 @@ &sdhci0 {
        pinctrl-0 = <&main_mmc0_pins_default>;
        status = "okay";
        bootph-all;
+       /delete-property/ ti,otap-del-sel-hs200;
 };
 
 &sdhci1 {

  • 0 in reply to Bin Liu
    Prodigy 160 points

    Hi Bin,

    HS DDR mode needs to be added first. Otherwise the fallback will be SDR mode.

    +++ b/arch/arm64/boot/dts/ti/k3-am62l-main.dtsi
@@ -310,11 +310,12 @@ sdhci0: mmc@fa10000 {
                assigned-clocks = <&scmi_clk 125>;
                assigned-clock-parents = <&scmi_clk 124>;
                bus-width = <8>;
-               mmc-hs200-1_8v;
+               mmc-ddr-1_8v;
                ti,clkbuf-sel = <0x7>;
                ti,otap-del-sel-legacy = <0x0>;
                ti,otap-del-sel-mmc-hs = <0x0>;
-               ti,otap-del-sel-hs200 = <0x6>;
+               ti,otap-del-sel-ddr52 = <0x6>;
+               ti,itap-del-sel-ddr52 = <0x3>;
                status = "disabled";
        };


    I'm wondering if there is any verification necessary from your side for HS DDR mode.

    We would do of course our own emc and climate chamber tests.

    Thanks

    Dominik

  • +1 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    Yes you are right, the patch I did is for HS SDR mode. Sorry about that.

    + ti,otap-del-sel-ddr52 = <0x6>;
    + ti,itap-del-sel-ddr52 = <0x3>;

    But your otap/itap delay values for DDR52 do not seem to match the AM62L Datasheet.

  • 0 in reply to Bin Liu
    Prodigy 160 points

    Thanks, I think I just copied the values from another SoC...
    The same test that showed errors with HS200 was running fine though even with the wrong delay settings.

    So from my side there aren't any open questions for now. We just have to see if we're able to achieve stable HS200 in hardware.

    If not we'll either have your (by then) reviewed workaround or we have to downgrade the speed mode.

    Best regards

    Dominik

  • 0 in reply to Dominik Haller
    TI__Guru**** 171861 points

    Hi Dominik,

    Sounds a good plan. I am closing this ticket for now.