[PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Markus Schneider-Pargmann (TI.com)]

Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
u-boot SPL is not able to read u-boot from mmc:

    Trying to boot from MMC2
    Error reading cluster
    spl_load_image_fat: error reading image u-boot.img, err - -22
    Error: -22
    SPL: Unsupported Boot Device!
    SPL: failed to boot from all boot devices
    ### ERROR ### Please RESET the board ###

I bisected this issue between u-boot v2025.10 and v2026.01 and found the
devicetree merge to be the problem. At a closer look I found the
k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
failure to read from mmc.

Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by default")
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
---
 arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 36 ++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..9129045c8bbd3a83dba6ff6f2148a3624b91b546 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
@@ -315,30 +315,30 @@ AM62AX_IOPAD(0x0b4, PIN_INPUT_PULLUP, 1) /* (K24) GPMC0_CSn3.I2C2_SDA */
 
 	main_mmc0_pins_default: main-mmc0-default-pins {
 		pinctrl-single,pins = <
-			AM62AX_IOPAD(0x220, PIN_INPUT, 0) /* (Y3) MMC0_CMD */
-			AM62AX_IOPAD(0x218, PIN_INPUT, 0) /* (AB1) MMC0_CLKLB */
-			AM62AX_IOPAD(0x21c, PIN_INPUT, 0) /* (AB1) MMC0_CLK */
-			AM62AX_IOPAD(0x214, PIN_INPUT, 0) /* (AA2) MMC0_DAT0 */
-			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP, 0) /* (AA1) MMC0_DAT1 */
-			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP, 0) /* (AA3) MMC0_DAT2 */
-			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP, 0) /* (Y4) MMC0_DAT3 */
-			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP, 0) /* (AB2) MMC0_DAT4 */
-			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP, 0) /* (AC1) MMC0_DAT5 */
-			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP, 0) /* (AD2) MMC0_DAT6 */
-			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP, 0) /* (AC2) MMC0_DAT7 */
+			AM62AX_IOPAD(0x220, PIN_INPUT_NOST, 0) /* (Y3) MMC0_CMD */
+			AM62AX_IOPAD(0x218, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLKLB */
+			AM62AX_IOPAD(0x21c, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLK */
+			AM62AX_IOPAD(0x214, PIN_INPUT_NOST, 0) /* (AA2) MMC0_DAT0 */
+			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP_NOST, 0) /* (AA1) MMC0_DAT1 */
+			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP_NOST, 0) /* (AA3) MMC0_DAT2 */
+			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP_NOST, 0) /* (Y4) MMC0_DAT3 */
+			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP_NOST, 0) /* (AB2) MMC0_DAT4 */
+			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP_NOST, 0) /* (AC1) MMC0_DAT5 */
+			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP_NOST, 0) /* (AD2) MMC0_DAT6 */
+			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP_NOST, 0) /* (AC2) MMC0_DAT7 */
 		>;
 		bootph-all;
 	};
 
 	main_mmc1_pins_default: main-mmc1-default-pins {
 		pinctrl-single,pins = <
-			AM62AX_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */
-			AM62AX_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */
-			AM62AX_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */
-			AM62AX_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */
-			AM62AX_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */
-			AM62AX_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */
-			AM62AX_IOPAD(0x240, PIN_INPUT, 0) /* (D17) MMC1_SDCD */
+			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
+			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
+			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
+			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
+			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
+			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
+			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */
 		>;
 		bootph-all;
 	};

---
base-commit: 6cd6c12031130a349a098dbeb19d8c3070d2dfbe
change-id: 20260106-topic-am62a-mmc-pinctrl-v6-19-next-2f3e5563fbb5

Best regards,
-- 
Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Markus,

I'm sorry my patch has caused regression for your use-case!

I think we would need to discuss this with TI via our FAE, because the change
in question has both been discussed with former FAE and the technical team
behind, and adopted in TI SDK.

Or have you already discused this with corresponding TI HW team?

Which hardware is affected, is it the official SK-AM62A-LP?
Is MMC2 the SD-card?

On Tue, 2026-01-06 at 17:22 +0100, Markus Schneider-Pargmann (TI.com) wrote:
> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> u-boot SPL is not able to read u-boot from mmc:
> 
>     Trying to boot from MMC2
>     Error reading cluster
>     spl_load_image_fat: error reading image u-boot.img, err - -22
>     Error: -22
>     SPL: Unsupported Boot Device!
>     SPL: failed to boot from all boot devices
>     ### ERROR ### Please RESET the board ###
> 
> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> devicetree merge to be the problem. At a closer look I found the
> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> failure to read from mmc.
> 
> Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by default")
> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
> ---
>  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 36 ++++++++++++++++-----------------
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..9129045c8bbd3a83dba6ff6f2148a3624b91b546 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -315,30 +315,30 @@ AM62AX_IOPAD(0x0b4, PIN_INPUT_PULLUP, 1) /* (K24) GPMC0_CSn3.I2C2_SDA */
>  
>  	main_mmc0_pins_default: main-mmc0-default-pins {
>  		pinctrl-single,pins = <
> -			AM62AX_IOPAD(0x220, PIN_INPUT, 0) /* (Y3) MMC0_CMD */
> -			AM62AX_IOPAD(0x218, PIN_INPUT, 0) /* (AB1) MMC0_CLKLB */
> -			AM62AX_IOPAD(0x21c, PIN_INPUT, 0) /* (AB1) MMC0_CLK */

according to datasheet, MMC0_CLK should have address 0x218 and it's the ball AB7.
MMC0_CLKLB is not present in the datasheet and AB1 is actually VSS. 0x21C address
is not documented.

Something is not right here...

OK, grepping TRM for CLKLB, one can conclude that 0x21c is actually MMC0_CLKLB.

Could you please try to modify 0x21c address only? Does it solve the boot problem?

> -			AM62AX_IOPAD(0x214, PIN_INPUT, 0) /* (AA2) MMC0_DAT0 */
> -			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP, 0) /* (AA1) MMC0_DAT1 */
> -			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP, 0) /* (AA3) MMC0_DAT2 */
> -			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP, 0) /* (Y4) MMC0_DAT3 */
> -			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP, 0) /* (AB2) MMC0_DAT4 */
> -			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP, 0) /* (AC1) MMC0_DAT5 */
> -			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP, 0) /* (AD2) MMC0_DAT6 */
> -			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP, 0) /* (AC2) MMC0_DAT7 */

All the rest actually have ST enabled on PoR according to TRM and I suppose BootROM
would have had hard times booting from the affected MMC device if it would not be
the correct setting?

> +			AM62AX_IOPAD(0x220, PIN_INPUT_NOST, 0) /* (Y3) MMC0_CMD */
> +			AM62AX_IOPAD(0x218, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLKLB */
> +			AM62AX_IOPAD(0x21c, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLK */
> +			AM62AX_IOPAD(0x214, PIN_INPUT_NOST, 0) /* (AA2) MMC0_DAT0 */
> +			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP_NOST, 0) /* (AA1) MMC0_DAT1 */
> +			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP_NOST, 0) /* (AA3) MMC0_DAT2 */
> +			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP_NOST, 0) /* (Y4) MMC0_DAT3 */
> +			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP_NOST, 0) /* (AB2) MMC0_DAT4 */
> +			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP_NOST, 0) /* (AC1) MMC0_DAT5 */
> +			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP_NOST, 0) /* (AD2) MMC0_DAT6 */
> +			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP_NOST, 0) /* (AC2) MMC0_DAT7 */
>  		>;
>  		bootph-all;
>  	};
>  
>  	main_mmc1_pins_default: main-mmc1-default-pins {
>  		pinctrl-single,pins = <
> -			AM62AX_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */
> -			AM62AX_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */
> -			AM62AX_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */
> -			AM62AX_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */
> -			AM62AX_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */
> -			AM62AX_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */
> -			AM62AX_IOPAD(0x240, PIN_INPUT, 0) /* (D17) MMC1_SDCD */

All of these have ST enabled on PoR, according to TRM.

> +			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
> +			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
> +			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
> +			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
> +			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
> +			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
> +			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */
>  		>;
>  		bootph-all;
>  	};
> 
> ---
> base-commit: 6cd6c12031130a349a098dbeb19d8c3070d2dfbe
> change-id: 20260106-topic-am62a-mmc-pinctrl-v6-19-next-2f3e5563fbb5
> 
> Best regards,

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Markus Schneider-Pargmann]

[-- Attachment #1: Type: text/plain, Size: 5957 bytes --]

Hi Alexander,

On Tue Jan 6, 2026 at 6:25 PM CET, Alexander Sverdlin wrote:
> Hi Markus,
>
> I'm sorry my patch has caused regression for your use-case!
>
> I think we would need to discuss this with TI via our FAE, because the change
> in question has both been discussed with former FAE and the technical team
> behind, and adopted in TI SDK.
>
> Or have you already discused this with corresponding TI HW team?
>
> Which hardware is affected, is it the official SK-AM62A-LP?
> Is MMC2 the SD-card?

I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
MMC2 is the SD-card and mmc1 in the devicetree.

I am using u-boot's am62ax_evm_r5_defconfig and am62ax_evm_a53_defconfig
as defconfigs.

>
> On Tue, 2026-01-06 at 17:22 +0100, Markus Schneider-Pargmann (TI.com) wrote:
>> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
>> u-boot SPL is not able to read u-boot from mmc:
>> 
>>     Trying to boot from MMC2
>>     Error reading cluster
>>     spl_load_image_fat: error reading image u-boot.img, err - -22
>>     Error: -22
>>     SPL: Unsupported Boot Device!
>>     SPL: failed to boot from all boot devices
>>     ### ERROR ### Please RESET the board ###
>> 
>> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
>> devicetree merge to be the problem. At a closer look I found the
>> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
>> failure to read from mmc.
>> 
>> Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by default")
>> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
>> ---
>>  arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 36 ++++++++++++++++-----------------
>>  1 file changed, 18 insertions(+), 18 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..9129045c8bbd3a83dba6ff6f2148a3624b91b546 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> @@ -315,30 +315,30 @@ AM62AX_IOPAD(0x0b4, PIN_INPUT_PULLUP, 1) /* (K24) GPMC0_CSn3.I2C2_SDA */
>>  
>>  	main_mmc0_pins_default: main-mmc0-default-pins {
>>  		pinctrl-single,pins = <
>> -			AM62AX_IOPAD(0x220, PIN_INPUT, 0) /* (Y3) MMC0_CMD */
>> -			AM62AX_IOPAD(0x218, PIN_INPUT, 0) /* (AB1) MMC0_CLKLB */
>> -			AM62AX_IOPAD(0x21c, PIN_INPUT, 0) /* (AB1) MMC0_CLK */
>
> according to datasheet, MMC0_CLK should have address 0x218 and it's the ball AB7.
> MMC0_CLKLB is not present in the datasheet and AB1 is actually VSS. 0x21C address
> is not documented.
>
> Something is not right here...
>
> OK, grepping TRM for CLKLB, one can conclude that 0x21c is actually MMC0_CLKLB.
>
> Could you please try to modify 0x21c address only? Does it solve the boot problem?
>
>> -			AM62AX_IOPAD(0x214, PIN_INPUT, 0) /* (AA2) MMC0_DAT0 */
>> -			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP, 0) /* (AA1) MMC0_DAT1 */
>> -			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP, 0) /* (AA3) MMC0_DAT2 */
>> -			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP, 0) /* (Y4) MMC0_DAT3 */
>> -			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP, 0) /* (AB2) MMC0_DAT4 */
>> -			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP, 0) /* (AC1) MMC0_DAT5 */
>> -			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP, 0) /* (AD2) MMC0_DAT6 */
>> -			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP, 0) /* (AC2) MMC0_DAT7 */
>
> All the rest actually have ST enabled on PoR according to TRM and I suppose BootROM
> would have had hard times booting from the affected MMC device if it would not be
> the correct setting?
>
>> +			AM62AX_IOPAD(0x220, PIN_INPUT_NOST, 0) /* (Y3) MMC0_CMD */
>> +			AM62AX_IOPAD(0x218, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLKLB */
>> +			AM62AX_IOPAD(0x21c, PIN_INPUT_NOST, 0) /* (AB1) MMC0_CLK */
>> +			AM62AX_IOPAD(0x214, PIN_INPUT_NOST, 0) /* (AA2) MMC0_DAT0 */
>> +			AM62AX_IOPAD(0x210, PIN_INPUT_PULLUP_NOST, 0) /* (AA1) MMC0_DAT1 */
>> +			AM62AX_IOPAD(0x20c, PIN_INPUT_PULLUP_NOST, 0) /* (AA3) MMC0_DAT2 */
>> +			AM62AX_IOPAD(0x208, PIN_INPUT_PULLUP_NOST, 0) /* (Y4) MMC0_DAT3 */
>> +			AM62AX_IOPAD(0x204, PIN_INPUT_PULLUP_NOST, 0) /* (AB2) MMC0_DAT4 */
>> +			AM62AX_IOPAD(0x200, PIN_INPUT_PULLUP_NOST, 0) /* (AC1) MMC0_DAT5 */
>> +			AM62AX_IOPAD(0x1fc, PIN_INPUT_PULLUP_NOST, 0) /* (AD2) MMC0_DAT6 */
>> +			AM62AX_IOPAD(0x1f8, PIN_INPUT_PULLUP_NOST, 0) /* (AC2) MMC0_DAT7 */
>>  		>;
>>  		bootph-all;
>>  	};
>>  
>>  	main_mmc1_pins_default: main-mmc1-default-pins {
>>  		pinctrl-single,pins = <
>> -			AM62AX_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */
>> -			AM62AX_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */
>> -			AM62AX_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */
>> -			AM62AX_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */
>> -			AM62AX_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */
>> -			AM62AX_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */
>> -			AM62AX_IOPAD(0x240, PIN_INPUT, 0) /* (D17) MMC1_SDCD */
>
> All of these have ST enabled on PoR, according to TRM.
>
>> +			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
>> +			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
>> +			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
>> +			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
>> +			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
>> +			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
>> +			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */

My board is setup to boot from SD card for easier u-boot testing. So
only the mmc1 is relevant for my setup. I just tested which pins need
NOST here for the boot to work, all DAT pins need the NOST variants,
otherwise it does not boot here. Not sure if this is just my board or it
fails on other boards as well.

Best
Markus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Markus,

short update from my side:

> > I think we would need to discuss this with TI via our FAE, because the change
> > in question has both been discussed with former FAE and the technical team
> > behind, and adopted in TI SDK.

I've reported this to the new FAE at TI, let's see how quickly relevant
people at TI could look into it... I unfortunately don't have access to
AM62A7 HW, but I've re-tested SD card on our AM623-based HW and I see no
issues under Linux.

> 
> > > +			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
> > > +			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
> > > +			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
> > > +			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
> > > +			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
> > > +			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
> > > +			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */
> 
> My board is setup to boot from SD card for easier u-boot testing. So
> only the mmc1 is relevant for my setup. I just tested which pins need
> NOST here for the boot to work, all DAT pins need the NOST variants,
> otherwise it does not boot here. Not sure if this is just my board or it
> fails on other boards as well.

Thanks for checking this!
I'm curious: is it only U-Boot issue? Does the card work properly if you
still have ST enabled in Linux?

I'm a bit hesitatnt to revert the ST on these (or any other) pins without
understanding what's going on in HW, because from all our discussions with
TI we've concluded that ST shall be used on all pins without any drawbacks.

Getting this back to TI will also help them to figure out the HW requirements
and document them better.

I'll keep you informed, shall I have any new info...

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Markus,

On Tue, 2026-01-06 at 21:25 +0100, Markus Schneider-Pargmann wrote:
> > I think we would need to discuss this with TI via our FAE, because the change
> > in question has both been discussed with former FAE and the technical team
> > behind, and adopted in TI SDK.
> > 
> > Or have you already discused this with corresponding TI HW team?
> > 
> > Which hardware is affected, is it the official SK-AM62A-LP?
> > Is MMC2 the SD-card?
> 
> I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
> MMC2 is the SD-card and mmc1 in the devicetree.

just wanted to let you know, I was able to reproduce the problems with SD
card access via MMC2 under Linux on AM623 with ST enabled.

We will seek clarification from TI on why this happens, which peripherals
are affected and what should be the course of actions.

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Nishanth Menon]

On 23:57-20260107, Alexander Sverdlin wrote:
> Hi Markus,
> 
> On Tue, 2026-01-06 at 21:25 +0100, Markus Schneider-Pargmann wrote:
> > > I think we would need to discuss this with TI via our FAE, because the change
> > > in question has both been discussed with former FAE and the technical team
> > > behind, and adopted in TI SDK.
> > > 
> > > Or have you already discused this with corresponding TI HW team?
> > > 
> > > Which hardware is affected, is it the official SK-AM62A-LP?
> > > Is MMC2 the SD-card?
> > 
> > I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
> > MMC2 is the SD-card and mmc1 in the devicetree.
> 
> just wanted to let you know, I was able to reproduce the problems with SD
> card access via MMC2 under Linux on AM623 with ST enabled.
> 
> We will seek clarification from TI on why this happens, which peripherals
> are affected and what should be the course of actions.


I have passed this up the chain here at TI. What confuses the heck out
of me is this: from an internal email chain I am privy to, i am being
told that "the ST_EN bit in every PADCONFIG register should never be
changed from its power-on default state of 0b1" and the fact that Linux
kernel has been stable with the setting for a long period, So I am
confused why U-Boot would show this instability.. I don't have answers
at the moment. until we clarify the reasoning, I am going to have to
hold off this given that kernel behavior has not regressed that I am
aware of.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Sverdlin, Alexander]

Hi Nishanth!

> > > > I think we would need to discuss this with TI via our FAE, because the change
> > > > in question has both been discussed with former FAE and the technical team
> > > > behind, and adopted in TI SDK.
> > > > 
> > > > Or have you already discused this with corresponding TI HW team?
> > > > 
> > > > Which hardware is affected, is it the official SK-AM62A-LP?
> > > > Is MMC2 the SD-card?
> > > 
> > > I only tested my am62a board on u-boot v2026.01. It is a SK-AM62A-LP.
> > > MMC2 is the SD-card and mmc1 in the devicetree.
> > 
> > just wanted to let you know, I was able to reproduce the problems with SD
> > card access via MMC2 under Linux on AM623 with ST enabled.
> > 
> > We will seek clarification from TI on why this happens, which peripherals
> > are affected and what should be the course of actions.
> 
> 
> I have passed this up the chain here at TI. What confuses the heck out

Great, thanks Nishanth!

> of me is this: from an internal email chain I am privy to, i am being
> told that "the ST_EN bit in every PADCONFIG register should never be
> changed from its power-on default state of 0b1" and the fact that Linux

that's the info we've got from FAE initially and...

> kernel has been stable with the setting for a long period, So I am

... realized that Linux actually did the exact opposite of it since the first K3s
(AM65) and though "Ouch!"

That's how I quickly came up with 5b272127884b and though "finally we are safe!"

And "stable" is relative, we've found it out because GPIOs did produce
spurious interrupts, it's just that most of the drivers can handle it
gracefully. Except interrupt event counters...

> confused why U-Boot would show this instability.. I don't have answers
> at the moment. until we clarify the reasoning, I am going to have to
> hold off this given that kernel behavior has not regressed that I am
> aware of.

Indeed, I've reproduced it with AM623 in Linux [1], even though it's not
TI evaluation board, it's our HW. We do have other HW design where the
problem doesn't manifest itself, so ST seems to put MMC on the edge somehow.

I can try to retest TI AM625 based EKs at some point, but it could take
some days on my side...

[1] https://lore.kernel.org/all/6c90102537c3e3f1712538ca0b165cd54d71d8c2.camel@gmail.com/

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Markus,

On Tue, 2026-01-06 at 18:25 +0100, Alexander Sverdlin wrote:
> >  	main_mmc1_pins_default: main-mmc1-default-pins {
> >  		pinctrl-single,pins = <
> > -			AM62AX_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */

this is a bit trial-and-error, but maybe you could try to add missing clock
retimer/loopback pin for test instead of disabling ST? Would this help:

			AM62AX_IOPAD(0x238, PIN_INPUT, 0) /* (N/A) MMC1_CLKLB */

some SoCs from AM6x family seem to require it even though TRMs claim the default
PoR state is the proper one.

> > -			AM62AX_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */
> > -			AM62AX_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */
> > -			AM62AX_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */
> > -			AM62AX_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */
> > -			AM62AX_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */
> > -			AM62AX_IOPAD(0x240, PIN_INPUT, 0) /* (D17) MMC1_SDCD */
> 
> All of these have ST enabled on PoR, according to TRM.
> 
> > +			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
> > +			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
> > +			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
> > +			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
> > +			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
> > +			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
> > +			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */
> >  		>;
> >  		bootph-all;
> >  	};

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Markus Schneider-Pargmann]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Hi Alexander,

On Wed Jan 7, 2026 at 3:49 PM CET, Alexander Sverdlin wrote:
> Hi Markus,
>
> On Tue, 2026-01-06 at 18:25 +0100, Alexander Sverdlin wrote:
>> >  	main_mmc1_pins_default: main-mmc1-default-pins {
>> >  		pinctrl-single,pins = <
>> > -			AM62AX_IOPAD(0x23c, PIN_INPUT, 0) /* (A21) MMC1_CMD */
>
> this is a bit trial-and-error, but maybe you could try to add missing clock
> retimer/loopback pin for test instead of disabling ST? Would this help:
>
> 			AM62AX_IOPAD(0x238, PIN_INPUT, 0) /* (N/A) MMC1_CLKLB */
>
> some SoCs from AM6x family seem to require it even though TRMs claim the default
> PoR state is the proper one.

Thanks, but adding that does not help unfortunately. And it seems ST
being enabled on that pin does not break it either. The data lines seem
to be the important ones.

Best
Markus

>
>> > -			AM62AX_IOPAD(0x234, PIN_INPUT, 0) /* (B22) MMC1_CLK */
>> > -			AM62AX_IOPAD(0x230, PIN_INPUT, 0) /* (A22) MMC1_DAT0 */
>> > -			AM62AX_IOPAD(0x22c, PIN_INPUT, 0) /* (B21) MMC1_DAT1 */
>> > -			AM62AX_IOPAD(0x228, PIN_INPUT, 0) /* (C21) MMC1_DAT2 */
>> > -			AM62AX_IOPAD(0x224, PIN_INPUT, 0) /* (D22) MMC1_DAT3 */
>> > -			AM62AX_IOPAD(0x240, PIN_INPUT, 0) /* (D17) MMC1_SDCD */
>> 
>> All of these have ST enabled on PoR, according to TRM.
>> 
>> > +			AM62AX_IOPAD(0x23c, PIN_INPUT_NOST, 0) /* (A21) MMC1_CMD */
>> > +			AM62AX_IOPAD(0x234, PIN_INPUT_NOST, 0) /* (B22) MMC1_CLK */
>> > +			AM62AX_IOPAD(0x230, PIN_INPUT_NOST, 0) /* (A22) MMC1_DAT0 */
>> > +			AM62AX_IOPAD(0x22c, PIN_INPUT_NOST, 0) /* (B21) MMC1_DAT1 */
>> > +			AM62AX_IOPAD(0x228, PIN_INPUT_NOST, 0) /* (C21) MMC1_DAT2 */
>> > +			AM62AX_IOPAD(0x224, PIN_INPUT_NOST, 0) /* (D22) MMC1_DAT3 */
>> > +			AM62AX_IOPAD(0x240, PIN_INPUT_NOST, 0) /* (D17) MMC1_SDCD */
>> >  		>;
>> >  		bootph-all;
>> >  	};


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Vitor Soares]

On Tue, 2026-01-06 at 17:22 +0100, Markus Schneider-Pargmann (TI.com) wrote:
> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> u-boot SPL is not able to read u-boot from mmc:
> 
>     Trying to boot from MMC2
>     Error reading cluster
>     spl_load_image_fat: error reading image u-boot.img, err - -22
>     Error: -22
>     SPL: Unsupported Boot Device!
>     SPL: failed to boot from all boot devices
>     ### ERROR ### Please RESET the board ###
> 
> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> devicetree merge to be the problem. At a closer look I found the
> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> failure to read from mmc.
> 
> Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by
> default")
> Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
> 
Hi Markus,

We're seeing a similar issue on Verdin AM62 with U-Boot 2026.01. The
board has complete SPL boot failure with no output at all.

This occurs in the same version you bisected (v2026.01 failing).
Could the Schmitt Trigger changes also affect Verdin AM62?

Best regards,
Vitor Soares

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Vitor,

On Thu, 2026-01-08 at 14:07 +0000, Vitor Soares wrote:
> On Tue, 2026-01-06 at 17:22 +0100, Markus Schneider-Pargmann (TI.com) wrote:
> > Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> > u-boot SPL is not able to read u-boot from mmc:
> > 
> >     Trying to boot from MMC2
> >     Error reading cluster
> >     spl_load_image_fat: error reading image u-boot.img, err - -22
> >     Error: -22
> >     SPL: Unsupported Boot Device!
> >     SPL: failed to boot from all boot devices
> >     ### ERROR ### Please RESET the board ###
> > 
> > I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> > devicetree merge to be the problem. At a closer look I found the
> > k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> > failure to read from mmc.
> > 
> > Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by
> > default")
> > Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
> > 
> Hi Markus,
> 
> We're seeing a similar issue on Verdin AM62 with U-Boot 2026.01. The
> board has complete SPL boot failure with no output at all.
> 
> This occurs in the same version you bisected (v2026.01 failing).
> Could the Schmitt Trigger changes also affect Verdin AM62?

they do affect AM62, even though not not every HW, I have one HW variant
working properly and one where I observe the problem. Maybe a revert
of 5b272127884b for now would make more sense than just fixing AM62A7.

I unfortunately do not have any reply on this from TI yet.

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Nishanth Menon]

On 14:07-20260108, Vitor Soares wrote:
> On Tue, 2026-01-06 at 17:22 +0100, Markus Schneider-Pargmann (TI.com) wrote:
> > Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> > u-boot SPL is not able to read u-boot from mmc:
> > 
> >     Trying to boot from MMC2
> >     Error reading cluster
> >     spl_load_image_fat: error reading image u-boot.img, err - -22
> >     Error: -22
> >     SPL: Unsupported Boot Device!
> >     SPL: failed to boot from all boot devices
> >     ### ERROR ### Please RESET the board ###
> > 
> > I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> > devicetree merge to be the problem. At a closer look I found the
> > k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> > failure to read from mmc.
> > 
> > Fixes: 5b272127884b ("arm64: dts: ti: k3-pinctrl: Enable Schmitt Trigger by
> > default")
> > Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
> > 
> Hi Markus,
> 
> We're seeing a similar issue on Verdin AM62 with U-Boot 2026.01. The
> board has complete SPL boot failure with no output at all.
> 
> This occurs in the same version you bisected (v2026.01 failing).
> Could the Schmitt Trigger changes also affect Verdin AM62?

Side note:

There seem to be multiple issues playing around in U-boot regression.
Please see
https://lore.kernel.org/all/20260108141233.GQ3416603@bill-the-cat/ as
well. There is chunk of discussions on #u-boot irc channel. I'd wait for
U-boot folks to settle things down

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

On 1/6/26 10:22 AM, Markus Schneider-Pargmann (TI.com) wrote:
> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> u-boot SPL is not able to read u-boot from mmc:
> 
>      Trying to boot from MMC2
>      Error reading cluster
>      spl_load_image_fat: error reading image u-boot.img, err - -22
>      Error: -22
>      SPL: Unsupported Boot Device!
>      SPL: failed to boot from all boot devices
>      ### ERROR ### Please RESET the board ###
> 
> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> devicetree merge to be the problem. At a closer look I found the
> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> failure to read from mmc.

I have tested 4 AM62A SK boards and I cannot replicate the issue
you are seeing. I do not see an issue with Schmitt Trigger in U-boot
nor Linux /:

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.

Also, are you able to replicate the issue on more than one board? Or is
this the only board you see the issue on?

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

Hi Markus,

On 1/14/26 3:16 AM, Markus Schneider-Pargmann wrote:
> Hi Judith,
> 
> On Tue Jan 13, 2026 at 1:29 AM CET, Judith Mendez wrote:
>> On 1/6/26 10:22 AM, Markus Schneider-Pargmann (TI.com) wrote:
>>> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
>>> u-boot SPL is not able to read u-boot from mmc:
>>>
>>>       Trying to boot from MMC2
>>>       Error reading cluster
>>>       spl_load_image_fat: error reading image u-boot.img, err - -22
>>>       Error: -22
>>>       SPL: Unsupported Boot Device!
>>>       SPL: failed to boot from all boot devices
>>>       ### ERROR ### Please RESET the board ###
>>>
>>> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
>>> devicetree merge to be the problem. At a closer look I found the
>>> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
>>> failure to read from mmc.
>>
>> I have tested 4 AM62A SK boards and I cannot replicate the issue
>> you are seeing. I do not see an issue with Schmitt Trigger in U-boot
>> nor Linux /:
> 
> Thanks for testing.
> 
>> 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.
> 
> The patch was a bit broken, but I think I managed to apply it to
> v2026.01 as it was supposed to be. (master currently doesn't boot even
> SPL, I don't have time right now to debug that).

as Nishanth, mentioned, master is missing two patches [0][1]

> 
> I attached the boot log. It does boot with your patch. Also can this be
> an issue with different SD cards?

Something does not quite add up,

Can you try the following 2 commands?

# mmc dev 1
# md.w 0xfa0810c


[0] https://gist.github.com/jmenti/92da6526e366e3f5cf41911724886471
[1] https://gist.github.com/jmenti/8cf589d0302248ad26da37128f622e98

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

Hi Markus, Alexander,

On 2/3/26 4:35 AM, Markus Schneider-Pargmann wrote:
> Hi Judith,
> 
> On Wed Jan 14, 2026 at 11:04 PM CET, Judith Mendez wrote:
>> Hi Markus,
>>
>> On 1/14/26 3:16 AM, Markus Schneider-Pargmann wrote:
>>> Hi Judith,
>>>
>>> On Tue Jan 13, 2026 at 1:29 AM CET, Judith Mendez wrote:
>>>> On 1/6/26 10:22 AM, Markus Schneider-Pargmann (TI.com) wrote:
>>>>> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
>>>>> u-boot SPL is not able to read u-boot from mmc:
>>>>>
>>>>>        Trying to boot from MMC2
>>>>>        Error reading cluster
>>>>>        spl_load_image_fat: error reading image u-boot.img, err - -22
>>>>>        Error: -22
>>>>>        SPL: Unsupported Boot Device!
>>>>>        SPL: failed to boot from all boot devices
>>>>>        ### ERROR ### Please RESET the board ###
>>>>>
>>>>> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
>>>>> devicetree merge to be the problem. At a closer look I found the
>>>>> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
>>>>> failure to read from mmc.
>>>>
>>>> I have tested 4 AM62A SK boards and I cannot replicate the issue
>>>> you are seeing. I do not see an issue with Schmitt Trigger in U-boot
>>>> nor Linux /:
>>>
>>> Thanks for testing.
>>>
>>>> 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.
>>>
>>> The patch was a bit broken, but I think I managed to apply it to
>>> v2026.01 as it was supposed to be. (master currently doesn't boot even
>>> SPL, I don't have time right now to debug that).
>>
>> as Nishanth, mentioned, master is missing two patches [0][1]
>>
>>>
>>> I attached the boot log. It does boot with your patch. Also can this be
>>> an issue with different SD cards?
>>
>> Something does not quite add up,
>>
>> Can you try the following 2 commands?
>>
>> # mmc dev 1
>> # md.w 0xfa0810c
> 
> Finally here is the output from boot and executing these commands. I am
> now on v2026.04-rc1 with your sweep patch.

Thanks for sending over the tap sweep. I compiled a comparison table
here to show a bit of data for the u-boot tuning step: 
https://gist.github.com/jmenti/5d42f1e43fb357083eaa813cfee484a8

Based on the data I can conclude the following:
1. you seem to have more errors than I do
2. there seems to be an issue with the chosen final tap setting
3. the chosen final tap setting should still have worked for you
but did not.

For #2, something in the tuning results seems off so let me investigate
this on my end and Ill get back.
For #3, will have to discuss this internally & test a couple more 
things, then come back with more information.

Meanwhile, I am interested to see what are the tap sweep results for the
failing Verdin board, if those can be sent as well, that would be great
info.

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Francesco Dolcini]

Hello Judith,

On Wed, Feb 04, 2026 at 08:03:39PM -0600, Judith Mendez wrote:
> On 2/3/26 4:35 AM, Markus Schneider-Pargmann wrote:
> > On Wed Jan 14, 2026 at 11:04 PM CET, Judith Mendez wrote:
> > > On 1/14/26 3:16 AM, Markus Schneider-Pargmann wrote:
> > > > On Tue Jan 13, 2026 at 1:29 AM CET, Judith Mendez wrote:
> > > > > On 1/6/26 10:22 AM, Markus Schneider-Pargmann (TI.com) wrote:
> > > > > > Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
> > > > > > u-boot SPL is not able to read u-boot from mmc:
> > > > > > 
> > > > > >        Trying to boot from MMC2
> > > > > >        Error reading cluster
> > > > > >        spl_load_image_fat: error reading image u-boot.img, err - -22
> > > > > >        Error: -22
> > > > > >        SPL: Unsupported Boot Device!
> > > > > >        SPL: failed to boot from all boot devices
> > > > > >        ### ERROR ### Please RESET the board ###
> > > > > > 
> > > > > > I bisected this issue between u-boot v2025.10 and v2026.01 and found the
> > > > > > devicetree merge to be the problem. At a closer look I found the
> > > > > > k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
> > > > > > failure to read from mmc.
> > > > > 
> > > > > I have tested 4 AM62A SK boards and I cannot replicate the issue
> > > > > you are seeing. I do not see an issue with Schmitt Trigger in U-boot
> > > > > nor Linux /:
> > > > 
> > > > Thanks for testing.
> > > > 
> > > > > 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.
> > > > 
> > > > The patch was a bit broken, but I think I managed to apply it to
> > > > v2026.01 as it was supposed to be. (master currently doesn't boot even
> > > > SPL, I don't have time right now to debug that).
> > > 
> > > as Nishanth, mentioned, master is missing two patches [0][1]
> > > 
> > > > 
> > > > I attached the boot log. It does boot with your patch. Also can this be
> > > > an issue with different SD cards?
> > > 
> > > Something does not quite add up,
> > > 
> > > Can you try the following 2 commands?
> > > 
> > > # mmc dev 1
> > > # md.w 0xfa0810c
> > 
> > Finally here is the output from boot and executing these commands. I am
> > now on v2026.04-rc1 with your sweep patch.
> 
> Thanks for sending over the tap sweep. I compiled a comparison table
> here to show a bit of data for the u-boot tuning step:
> https://gist.github.com/jmenti/5d42f1e43fb357083eaa813cfee484a8
> 
> Based on the data I can conclude the following:
> 1. you seem to have more errors than I do
> 2. there seems to be an issue with the chosen final tap setting
> 3. the chosen final tap setting should still have worked for you
> but did not.
> 
> For #2, something in the tuning results seems off so let me investigate
> this on my end and Ill get back.
> For #3, will have to discuss this internally & test a couple more things,
> then come back with more information.
> 
> Meanwhile, I am interested to see what are the tap sweep results for the
> failing Verdin board, if those can be sent as well, that would be great
> info.

Verdin is now booting fine. The boot failure was related to other U-Boot
bugs (as Nishanth mentioned) that are now fixed.

Thanks
Francesco

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

Hi Fransesco,

On 2/5/26 1:24 AM, Francesco Dolcini wrote:
> Hello Judith,
> 
> On Wed, Feb 04, 2026 at 08:03:39PM -0600, Judith Mendez wrote:
>> On 2/3/26 4:35 AM, Markus Schneider-Pargmann wrote:
>>> On Wed Jan 14, 2026 at 11:04 PM CET, Judith Mendez wrote:
>>>> On 1/14/26 3:16 AM, Markus Schneider-Pargmann wrote:
>>>>> On Tue Jan 13, 2026 at 1:29 AM CET, Judith Mendez wrote:
>>>>>> On 1/6/26 10:22 AM, Markus Schneider-Pargmann (TI.com) wrote:
>>>>>>> Remove Schmitt Trigger from mmc pins. With Schmitt Trigger enabled
>>>>>>> u-boot SPL is not able to read u-boot from mmc:
>>>>>>>
>>>>>>>         Trying to boot from MMC2
>>>>>>>         Error reading cluster
>>>>>>>         spl_load_image_fat: error reading image u-boot.img, err - -22
>>>>>>>         Error: -22
>>>>>>>         SPL: Unsupported Boot Device!
>>>>>>>         SPL: failed to boot from all boot devices
>>>>>>>         ### ERROR ### Please RESET the board ###
>>>>>>>
>>>>>>> I bisected this issue between u-boot v2025.10 and v2026.01 and found the
>>>>>>> devicetree merge to be the problem. At a closer look I found the
>>>>>>> k3-pinctrl.h changes. Disabling the Schmitt Trigger fixes the u-boot SPL
>>>>>>> failure to read from mmc.
>>>>>>
>>>>>> I have tested 4 AM62A SK boards and I cannot replicate the issue
>>>>>> you are seeing. I do not see an issue with Schmitt Trigger in U-boot
>>>>>> nor Linux /:
>>>>>
>>>>> Thanks for testing.
>>>>>
>>>>>> 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.
>>>>>
>>>>> The patch was a bit broken, but I think I managed to apply it to
>>>>> v2026.01 as it was supposed to be. (master currently doesn't boot even
>>>>> SPL, I don't have time right now to debug that).
>>>>
>>>> as Nishanth, mentioned, master is missing two patches [0][1]
>>>>
>>>>>
>>>>> I attached the boot log. It does boot with your patch. Also can this be
>>>>> an issue with different SD cards?
>>>>
>>>> Something does not quite add up,
>>>>
>>>> Can you try the following 2 commands?
>>>>
>>>> # mmc dev 1
>>>> # md.w 0xfa0810c
>>>
>>> Finally here is the output from boot and executing these commands. I am
>>> now on v2026.04-rc1 with your sweep patch.
>>
>> Thanks for sending over the tap sweep. I compiled a comparison table
>> here to show a bit of data for the u-boot tuning step:
>> https://gist.github.com/jmenti/5d42f1e43fb357083eaa813cfee484a8
>>
>> Based on the data I can conclude the following:
>> 1. you seem to have more errors than I do
>> 2. there seems to be an issue with the chosen final tap setting
>> 3. the chosen final tap setting should still have worked for you
>> but did not.
>>
>> For #2, something in the tuning results seems off so let me investigate
>> this on my end and Ill get back.
>> For #3, will have to discuss this internally & test a couple more things,
>> then come back with more information.
>>
>> Meanwhile, I am interested to see what are the tap sweep results for the
>> failing Verdin board, if those can be sent as well, that would be great
>> info.
> 
> Verdin is now booting fine. The boot failure was related to other U-Boot
> bugs (as Nishanth mentioned) that are now fixed.

Good to know, that isolates the issue to only one board.

Thanks.

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Alexander Sverdlin]

Hi Judith,

On Thu, 2026-02-05 at 11:07 -0600, Judith Mendez wrote:
> > Verdin is now booting fine. The boot failure was related to other U-Boot
> > bugs (as Nishanth mentioned) that are now fixed.
> 
> Good to know, that isolates the issue to only one board.

not really, as I mentioned, I had observed some issues with one of our
internal development boards, but I can only provide the data after couple of
weeks, after my vacation.

-- 
Alexander Sverdlin.

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Sverdlin, Alexander]

Hi Judith,

On Wed, 2026-02-04 at 20:03 -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

what do I miss?

> > > > The patch was a bit broken, but I think I managed to apply it to
> > > > v2026.01 as it was supposed to be. (master currently doesn't boot even
> > > > SPL, I don't have time right now to debug that).

[]

> > > > I attached the boot log. It does boot with your patch. Also can this be
> > > > an issue with different SD cards?
> > > 
> > > Something does not quite add up,
> > > 
> > > Can you try the following 2 commands?
> > > 
> > > # mmc dev 1
> > > # md.w 0xfa0810c
> > 
> > Finally here is the output from boot and executing these commands. I am
> > now on v2026.04-rc1 with your sweep patch.
> 
> Thanks for sending over the tap sweep. I compiled a comparison table
> here to show a bit of data for the u-boot tuning step: 
> https://gist.github.com/jmenti/5d42f1e43fb357083eaa813cfee484a8

If the above doubts have any substance, maybe those are not the results
you've expected at the end?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Sverdlin, Alexander]

On Tue, 2026-02-17 at 13:57 +0100, Alexander Sverdlin 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

typo: "omap" -> "otap"

> 
> what do I miss?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Sverdlin, Alexander]

On Tue, 2026-02-17 at 13:57 +0100, Alexander Sverdlin 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...

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

Hi Alexander,

On 2/17/26 7:23 AM, Sverdlin, Alexander wrote:
> On Tue, 2026-02-17 at 13:57 +0100, Alexander Sverdlin 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?

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Judith Mendez]

On 2/19/26 6:10 PM, Judith Mendez wrote:
> Hi Alexander,
> 
> On 2/17/26 7:23 AM, Sverdlin, Alexander wrote:
>> On Tue, 2026-02-17 at 13:57 +0100, Alexander Sverdlin 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?

~ Judith

Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Disable mmc Schmitt Trigger

[Sverdlin, Alexander]

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