Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger
From: Sverdlin, Alexander
Date: Mon Mar 16 2026 - 08:23:16 EST
Hi Judith,
On Thu, 2026-02-19 at 18:42 -0600, Judith Mendez wrote:
> > > > > > > > > Can you please run a quick tap sweep on MMC1 and MMC0 interfaces
> > > > > > > > > like
> > > > > > > > > so? https://gist.github.com/jmenti/f4a73a8323e44bf717c6d2c528c499ca
> > > > > > > > >
> > > > > > > > > This will give me an idea if whether we should be talking about
> > > > > > > > > revisiting characterization with ST_ENA=1.
> > > >
> > > > I wanted to apply your patch and test on our HW, but I have some
> > > > doubts, if
> > > > the patch maybe missing something:
> > > >
> > > > - am654_sdhci_write_otapdly() turns out to be unused in any upstream
> > > > U-Boot version
> > > > - new "omap" variable in am654_sdhci_execute_tuning() is in fact
> > > > unused as well
> > >
> > > and
> > >
> > > > /home/sverdlin/u-boot/drivers/mmc/am654_sdhci.c: In function
> > > 'j721e_4bit_sdhci_set_ios_post':
> > > > /home/sverdlin/u-boot/drivers/mmc/am654_sdhci.c:598:9: error:
> > > 'itap_del_sel' is used uninitialized [-Werror=uninitialized]
> > > > 598 | printf("j721e_4bit_sdhci_set_ios_post, mode=%d,
> > > otap=%d, itap=%d\n", mode, otap_del_sel, itap_del_sel);
> > > > |
> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > /home/sverdlin/u-boot/drivers/mmc/am654_sdhci.c:594:13: note:
> > > 'itap_del_sel' was declared here
> > > > 594 | u32 itap_del_sel;
> > > > | ^~~~~~~~~~~~
> > >
> > >
> > > so I'm not sure regarding the previous test results at all any longer..
> >
> > Sorry for the late reply, somehow I missed this email.
> >
> > Oh my, I am not sure what happend but seems like I did not copy the
> > whole patch correctly. Were you able to bypass or do you need me
> > to rebase the patch and copy correctly?
> >
>
> Your response actually explains why Marcus's log did not make
> sense at all, thanks. Here is the updated patch in case you need
> it: https://gist.github.com/f4a73a8323e44bf717c6d2c528c499ca.git
>
> Markus, can you try with this patch instead?
sorry for the delay, it took me some time until I was able to debug why
your last patch crashes U-Boot after emmc tuning:
For otap=31, itap=31 :PASS
am654_sdhci_write_itapdly, write itapdly=15
"Synchronous Abort" handler, esr 0x8a000000, far 0x14010000c31714ed
elr: 1401000083a2b4ed lr : 1401000083a2b4ed (reloc)
elr: 14010000c31714ed lr : 14010000c31714ed
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 000000000000010c x3 : 00000000bfad5538
x4 : 0000000000000004 x5 : 0000000000000000
x6 : 0000000000000400 x7 : 0000000000000110
x8 : 000000000010f30f x9 : 00000000bfb29cd0
x10: 000000000000010c x11: 0000000000000200
x12: 00000000bfb15888 x13: 00000000bfb159b0
x14: 00000000ffffffff x15: 00000000bfad5091
x16: 00000000bff84078 x17: 0000000000000000
x18: 00000000bfb25db0 x19: 0417140100008117
x20: 00000000bffb7aa0 x21: 00000000bffb7990
x22: 000000000000000a x23: 0000000070000419
x24: 0000000000000002 x25: 0000000000000005
x26: 0000000000000001 x27: 00000000bffb79b4
x28: 0000000000000000 x29: 0000041714ae0000
It turns out, it writes way beyond fail_window[] boundaries... But
I've captured couple of runs on the boards that were affected on our side
after applying this patch:
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -494,7 +494,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
{
struct udevice *dev = mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
- struct window fail_window[ITAPDLY_LENGTH];
+ struct window fail_window[ITAPDLY_LENGTH * ITAPDLY_LENGTH / 2];
int mode = mmc->selected_mode;
u8 curr_pass, itap, otap;
u8 fail_index = 0;
@@ -522,7 +522,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
if (!curr_pass) {
fail_window[fail_index].end = itap;
fail_window[fail_index].length++;
- printf("Failed otap=%d, itap=%d\n", otap, itap);
+ printf("Failed otap=%d, itap=%d (%d)\n", otap, itap, fail_index);
}
if (curr_pass && !prev_pass)
I'll send you the logs separately as they are huge for the list.
(I get ~64 entries in the fail_window[] in my runs)
--
Alexander Sverdlin
Siemens AG
www.siemens.com