• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 26 replies
  • Subscribers 105 subscribers
  • Views 1139 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: Intermittent eMMC boot issue

TIDR
Genius 9375 points

Part Number: AM6442
Other Parts Discussed in Thread: AM62P, LP8733

Customer runs U-boot + Linux on a TI AM6442 based module. The vast majority of the time it boots and runs OK. Occasionally, after a software reboot, the system loads the bootloader from an 8GB Micron eMMC and (as part of the normal boot process for any eMMC) starts to detect and setup faster eMMC modes. In some situations, it runs into a problem where the eMMC times out and the system hangs. They  added a software reboot to get out of the hang and although the system restarts and again loads & runs to boot loader from the eMMC, it runs into the same problem. This results in a constant reboot cycle. Power cycle clears the problem.

The issue has been  observed  between 10 and 20 times, typically after the system has been rebooted after a software update. In these cases the systems have been up & running for several weeks. 

As part of debug process the customer has tried using a custom image that rebooted at the end of the bootloader instead of booting Linux.  They performed back 2 back reboots as fast as possible to see if they could trigger the failure condition. More than 15,000 reboot cycles were carried out without success. 1000's of reboots in many different configurations (heavy emmc read and writes, system idling , system performing software updates, etc) were also conducted. 

HS200 and HS400 modes are disabled for eMMC

The bootlog (both good and non-working) showed an error with EEPROM read:

SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121 

  1. Customer is investigating this to see if a potential I2C hang is tied to this error and the subsequent boot failure

And actual boot failure message is:

mmc_get_op_cond: uhs_en=0, -110

mmc_get_op_cond:mmc_send_op_cond() -110

Card did not respond to voltage select! : -110

spl: mmc init failed with error: -95

SPL: failed to boot from all boot devices

2. Customer also checking if eMMC reset is asserted correctly both hardware and software wise from AM644x to eMMC

 3. eMMC legacy mode seems to work so performance impact of that is being looked at.

If there are any other suggestions on things to check please let me know.

Thanks!

  • 0
    TI__Guru* 85925 points

    Responses maybe delayed as Monday is a TI US holiday. 

    Please continue to share any additional relevant information from the suggested follow up action items above. 

  • 0
    Prodigy 60 points
    TIDR said:
    Customer is investigating this to see if a potential I2C hang is tied to this error and the subsequent boot failure

    We have reviewed the I2C and can say that based on further testing, the I2C message is benign. It is reported because a device that is not present is being probed. We also confirmed that electrically SDA operates normally using an oscilloscope. To check for possible boot hang, we forced a short across SDA and were able to confirm that the boot completes normally with some additional messages:

    Timed out in wait_for_bb: status=1000
    Timed out in wait_for_bb: status=1000
    Timed out in wait_for_bb: status=1000
    EEPROM not available at 0x50, trying to read at 0x51
    Timed out in wait_for_bb: status=1000
    Reading on-board EEPROM at 0x51 failed -121
    TIDR said:
    Customer also checking if eMMC reset is asserted correctly both hardware and software wise from AM644x to eMMC

    We also looked at the reset going into the eMMC and the timings look OK, measuring 158uS.

    We are curious about this issue

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1402424/am6442-micron-emmc-chip-at-tmds64evm-b-not-answering-after-a-second-sotfware-reset-cmd-second-mmcsd-driver-init

    which sounds related and would appreciate comment in the context of our current eMMC problems.

    TIDR said:
    eMMC legacy mode seems to work so performance impact of that is being looked at.

    Currently work-in-progress.

    Thank you.

  • 0 in reply to Will Frazer
    TI__Guru**** 179926 points

    Hi Will,

    Thanks for the update.

    Will Frazer said:
    We also looked at the reset going into the eMMC and the timings look OK, measuring 158uS.

    I reviewed the provided failure boot log, and I don't think the issue is related to eMMC reset. the log shows ROM is able to load/run R5 SPL (tiboot3.bin) from eMMC, and R5 SPL is able to load/run A53 SPL (tispl.bin) from eMMC too, then the eMMC failure happens when A53 SPL tries to load A53 U-Boot (u-boot.img). So eMMC seems to be working fine in reading tiboot3.bin and tispl.bin, it seems to be reset properly by the warm-reset signal.

    Will Frazer said:
    eMMC legacy mode seems to work so performance impact of that is being looked at.

    Can you please show the U-Boot patch for configuring eMMC to legacy mode?

    The boot log shows SYSFW version v10.1.8, do you use U-Boot from AM64x SDK v10.1? There are some U-Boot MMC driver update in SDK11.2 which are related to MMC timing, I need to check if those patches should be back ported to SDK10.1 U-Boot for you to test.

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Thanks for the update.

    Bin Liu said:
    Can you please show the U-Boot patch for configuring eMMC to legacy mode?

    Currently we are not forcing this mode. i.e. we believe that when the eMMC is reset, it starts in this mode and given that it appears to be readable until we get the timeout, we felt that legacy mode was apparently not exhibiting a problem. Our follow-up intention was to force the eMMC to stay in this mode and not attempt to use faster modes to see if the problem still occurred and also whether the kernel code was better able to deal with the eMMC state. When we have a patch to force this mode, I can share though ideally, this would be for test purposes, at least initially.

    Bin Liu said:
    The boot log shows SYSFW version v10.1.8, do you use U-Boot from AM64x SDK v10.1?

    Our U-Boot sources date from 2024 and I believe SDK v10.1 does too, however I need to compare the baselines to understand alignment. I am certainly interested in knowing more about the SDK11.2 updates particularly related to MMC timing. Thanks.

  • 0 in reply to Will Frazer
    TI__Guru**** 179926 points

    Hi Will,

    Will Frazer said:
    When we have a patch to force this mode, I can share though ideally, this would be for test purposes, at least initially.

    I agree forcing to legacy mode doesn't resolve the issue. So this work should be a lower priority.

    Will Frazer said:
    I am certainly interested in knowing more about the SDK11.2 updates particularly related to MMC timing.

    A quick check on U-Boot since SDK v10.1 release tag, there are 18 patches to the AM62x MMC controller driver.

    ti-u-boot.git$ glog 10.01.10.. drivers/mmc/am654_sdhci.c
    0fea7f943734 FROMLIST: mmc: am654_sdhci: Disable HS400 for AM62P SR1.0 and SR1.1
    98b6b3f5a259 (tag: cicd.scarthgap.202505151402, tag: 11.00.13) PENDING: mmc: am654_sdhci: Clear UHS_MODE_SELECT
    ee6c46a606bf FROMLIST: mmc: am654_sdhci: Add am654_sdhci_set_control_reg
    cd91d7360181 (tag: cicd.scarthgap.202503251551, tag: 11.00.09) PENDING: mmc: am654_sdhci: Unset HIGH_SPEED_ENA for MMC_HS_52
    804035fae6ea PENDING: mmc: am654_sdhci: Add MMC_HS_52 to timing data
    36e384d4eef5 PENDING: mmc: am654_sdhci: Set HIGH_SPEED_ENA for SDR12 and SDR25
    f2be440ceb3c PENDING: mmc: am654_sdhci: Fix possible NULL deref
    afdce7686371 mmc: am654_sdhci: Add the quirk to set TESTCD bit
    03de305ec48b Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"
    d678a59d2d71 Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""
    7938ac657ba6 mmc: Remove <common.h> and add needed includes
    2143a11e6149 mmc: Migrate MMC_SUPPORTS_TUNING to Kconfig
    f13a830e6e4a mmc: am654_sdhci: Fix ITAPDLY for HS400 timing
    a124e31a97cd mmc: am654_sdhci: Set ENDLL=1 for DDR52 mode
    056af04a39ae mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena bit
    5048b5c61afd mmc: am654_sdhci: Fix OTAP/ITAP delay values
    6b8dd9ca6e06 mmc: am654_sdhci: Add tuning algorithm for delay chain
    a3b2786651c7 mmc: Drop unused mmc_send_tuning() cmd_error parameter

    Instead of identifying which patches to back port, do you think it is better for you just compile the SDK11.02 U-Boot code base and test it on your board?

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Hi Bin Liu,

    Bin Liu said:
    A quick check on U-Boot since SDK v10.1 release tag, there are 18 patches to the AM62x MMC controller driver.

    We will review the list of patches, thanks.

    In the design, we have an LP8733 PMIC and tried to perform a SW_RESET in an effort to power-cycle the eMMC however, it seems that the SW_RESET command removed power from the PMIC outputs but did not re-enable them so the system did not restart. If the PMIC be encouraged to do what we want, this could be a viable way to exit the reset loop and recover from the problem.

    Previously, I linked another E2E ticket & wondered if you had see it & whether you thought this might be related to what we are seeing. 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1402424/am6442-micron-emmc-chip-at-tmds64evm-b-not-answering-after-a-second-sotfware-reset-cmd-second-mmcsd-driver-init

  • 0 in reply to Will Frazer
    TI__Mastermind 27266 points

    Hi Will, 

    The software reset for the LP8733 PMIC is more like a COLD reset that triggers a power-down sequence and turns OFF all regulators. PMIC does not have an I2C command to only toggle the PGOOD/PORz. 

    Thanks,

    Brenda

  • 0 in reply to Brenda Diaz
    TI__Guru* 94701 points

    Hi Will, 

    regarding the thread you reference, we believe this could be a possible cause.  It refers to a condition where the eMMC host controller may get into a state in which a re-initialization (ie, trying to initialize an already initialized controller) fails, and the only way to recover is to power down (or reset) the eMMC host controller to get it back into the power-up state.  This is done with an LPSC (Local Power/Sleep Controller). 

    A possible experiment would be to take the failed board that you have and reset the host controller, but this could only be done via JTAG.  Do you have JTAG access to that board?   

    With JTAG access, we could also attempt to dump the eMMC controller register to see what state it is in.  

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 60 points

    Hi James,

    Thanks for the reply.

    Unfortunately, JTAG has been removed from the board for security reasons.

  • 0 in reply to Brenda Diaz
    Prodigy 60 points

    Thanks Brenda, that aligns with the tests that we carried out.

  • 0 in reply to Will Frazer
    TI__Guru 64425 points

    My action item from the call today was to describe my proposal of asserting the system's cold reset without cycling power.

    I initially misunderstood what you were trying to do with the PMIC I2C command. I thought you were trying to assert the processor MCU_PORz reset input to see if the system recovers without cycling power.

    Now I understand you were hoping the I2C command would cycle power to the eMMC device, where the PMIC would sequence the supply rails down followed by a power-up sequence. As Brenda mentioned, the I2C command you sent will only result in a power-down sequence.

    You may want to consider the test I thought you were trying to do. It may help us understand what is happening if we asserted MCU_PORz without cycling power to see if a failing system recovers from just a cold reset. I would not expect there to be any difference between a power cycle and the assertion of cold reset without cycling power since the assertion of MCU_PORz is expected to reset every circuit in the processor.  This is not the case when you assert a warm reset.

    It may be possible to pull the MCU_PORz signal low from an external source connected to the PMIC reset output since its output is open-drain. The external source would need to produce a low pulse with the appropriate min pulse duration to ensure you do not violate the processor pulse width requirement. This min pulse width parameter of 1200ns is defined as RST3 in the datasheet MCU_PORz Timing Requirements table.

    As mentioned above, I'm expecting the cold reset to produce the same results as cycling power. Therefore, you may want to hold off on this test if you have more fruitful tests for a system that takes a long time to get into the failing state.

    Regards,
    Paul

  • 0 in reply to peaves
    TI__Guru 64425 points

    There was some confusion talking to Brenda last week, and portions of my previous reply is not correct. She saw my reply to E2E and sent a private email this morning to clarify how the LP8733 PMIC works.

    Brenda confirmed setting the SW_RESET bit will initiate a power-down sequence followed by a power-up sequence. She also confirmed there is no way to toggle the PMICs reset output without cycling power.

    Regards,
    Paul

  • 0 in reply to Will Frazer
    TI__Guru**** 179926 points

    Hi Will,

    I know that the eMMC lockup issue was initially reported in the field after system firmware update on eMMC, but have you ever reproduced the issue without updating the firmware on eMMC? I am trying to understand if the issue could be related to eMMC write transactions during the firmware update process.

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    I received offline response that confirms the issue has been seen without updating the firmware on eMMC.

    Hi Will,

    To continue the discussion about PMIC power down/up topic that we talked in today's meeting, can you please provide the details of the test procedure to trigger SW RESET to the PIMC on your board? For example, do you directly use i2c commands in Linux to access the PMIC registers, or use any Linux command which has i2c transfers to the PMIC implemented under the hood?

  • 0 in reply to Bin Liu
    Prodigy 10 points

    Hi Bin Lui.

    We used i2c from Linux.

    i2cset -f -y 0 0x61 0x18 0x1

     independently tried the same command and also the U-Boot equivalent.

  • 0 in reply to David Warman
    TI__Guru**** 179926 points

    Hi David,

    Attached are the SDK 10.1 U-Boot patches I use currently to dump eMMC debug log on AM64x EVM.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0002_2D00_dts_2D00_am64x_2D00_disable_2D00_eMMC_2D00_hs200.patch

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0003_2D00_configs_2D00_am64x_2D00_enable_2D00_eMMC_2D00_trace_2D00_and_2D00_debug.patch

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0004_2D00_mmc_2D00_dump_2D00_mmc_2D00_registers.patch

    And attached below is the console debug log for your reference.

    Fullscreen am64x-emmc-trace-0211-sdk101.log Download 
    �
U-Boot SPL 2024.04-00004-g82036fb1d6dd (Feb 11 2026 - 10:31:22 -0600)
k3_system_controller sysctrler: k3_of_to_priv: Acquiring optional Boot_notify failed. ret = -61. Using Rx
Resetting on cold boot to workaround ErrataID:i2331
Please resend tiboot3.bin in case of UART/DFU boot
resetting ...

U-Boot SPL 2024.04-00004-g82036fb1d6dd (Feb 11 2026 - 10:31:22 -0600)
k3_system_controller sysctrler: k3_of_to_priv: Acquiring optional Boot_notify failed. ret = -61. Using Rx
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
single-pinctrl pinctrl@f4000: configuring pins for main-i2c0-default-pins
single-pinctrl pinctrl@f4000:   reg/val /0x00060000
single-pinctrl pinctrl@f4000:   reg/val /0x00060000
ti_i2c_eeprom_am6_parse_record: Ignoring record id 17
k3_ddrss memorycontroller@f300000: ddr freq0 not populated, using bypass frequency.
k3_ddrss memorycontroller@f300000: vtt-supply not found.
SPL initial stack usage: 13392 bytes
pca953x gpio@38: gpio@38_ is ready
Trying to boot from MMC1
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sd-hs
am654_sdhci mmc@fa10000: Couldn't find 
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr12
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr25
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr50
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-ddr50
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr104
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-hs200
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-hs400
before am654_sdhci init:
phy_ctrl1 0x00010001, phy_ctrl2 0x00000000, phy_ctrl3 0x10ff30ff
phy_ctrl4 0x00000000, phy_ctrl5 0x00000000, phy_ctrl6 0x00000000

after sdhci SDHCI_RESET_ALL:
phy_ctrl1 0x00010001, phy_ctrl2 0x00000000, phy_ctrl3 0x10ff30ff
phy_ctrl4 0x00000000, phy_ctrl5 0x00000000, phy_ctrl6 0x00000000

mmc@fa10000: No vmmc supply
mmc@fa10000: No vqmmc supply
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00000000, PHY_CTRL5 0x00000000, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

clock is disabled (0Hz)
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

selecting mode MMC legacy (freq : 0 MHz)
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

clock is enabled (400000Hz)
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

CMD_SEND:0
		ARG			 0x00000000
		MMC_RSP_NONE
CMD_SEND:8
		ARG			 0x000000aa
		RET			 -110
CMD_SEND:55
		ARG			 0x00000000
		RET			 -110
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

CMD_SEND:0
		ARG			 0x00000000
		MMC_RSP_NONE
CMD_SEND:1
		ARG			 0x00000000
		MMC_RSP_R3,4		 0x00ff8080 
CMD_SEND:1
		ARG			 0x40000080
		MMC_RSP_R3,4		 0x00ff8080 
CMD_SEND:1
		ARG			 0x40000080
		MMC_RSP_R3,4		 0xc0ff8080 
CMD_SEND:2
		ARG			 0x00000000
		MMC_RSP_R2		 0x13014e53 
		          		 0x304a3536 
		          		 0x581031fb 
		          		 0xdcdc5900 

					DUMPING DATA
					000 - 13 01 4e 53 
					004 - 30 4a 35 36 
					008 - 58 10 31 fb 
					012 - dc dc 59 00 
CMD_SEND:3
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000500 
CMD_SEND:9
		ARG			 0x00010000
		MMC_RSP_R2		 0xd07f0132 
		          		 0x8f5903ff 
		          		 0xc003ffef 
		          		 0x86400000 

					DUMPING DATA
					000 - d0 7f 01 32 
					004 - 8f 59 03 ff 
					008 - c0 03 ff ef 
					012 - 86 40 00 00 
selecting mode MMC legacy (freq : 25 MHz)
CMD_SEND:7
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000700 
CMD_SEND:8
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000900 
mmc: widths [8, 4, 1, ] modes [MMC legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz), ]
host: widths [8, 4, 1, ] modes [MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz), ]
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x10, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

clock is enabled (25000000Hz)
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x10, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x407

trying mode MMC DDR52 (52MHz) width 8 (at 52 MHz)
CMD_SEND:6
		ARG			 0x03b70200
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
CMD_SEND:6
		ARG			 0x03b90100
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
CMD_SEND:6
		ARG			 0x03b70600
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
selecting mode MMC DDR52 (52MHz) (freq : 52 MHz)
PHY_CTRL1 0x00010001, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030007, PHY_CTRL6 0x00000000
HOST_CONTROL 0x30, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x407

clock is enabled (52000000Hz)
PHY_CTRL1 0x00010023, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00106103, PHY_CTRL5 0x00000407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x34, HOST_CONTROL2 0x04, CLOCK_CONTROL 0x207

CMD_SEND:8
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:6
		ARG			 0x03b34900
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
spl: mmc boot mode: raw
CMD_SEND:17
		ARG			 0x00000800
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:18
		ARG			 0x00000800
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:12
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000b00 
Authentication passed
Authentication passed
k3_arm64 a53@0: k3_arm64_probe
k3_arm64 a53@0: k3_arm64_of_to_priv
k3_arm64 a53@0: ti_sci_proc_of_to_priv
k3_arm64 a53@0: Remoteproc successfully probed
k3_arm64 a53@0: k3_arm64_init
k3_arm64 a53@0: k3_arm64_init: rproc successfully initialized
Loading Environment from nowhere... OK
init_env from device 9 not supported!
k3_arm64 a53@0: k3_arm64_load addr = 0x701c0000, size = 0x200
k3_arm64 a53@0: GTC RATE= 200000000
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

k3_arm64 a53@0: k3_arm64_start

U-Boot SPL 2024.04-00004-g82036fb1d6dd (Feb 11 2026 - 10:31:31 -0600)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
single-pinctrl pinctrl@f4000: configuring pins for main-i2c0-default-pins
single-pinctrl pinctrl@f4000:   reg/val /0x00060000
single-pinctrl pinctrl@f4000:   reg/val /0x00060000
pca953x gpio@38: gpio@38_ is ready
Trying to boot from MMC1
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sd-hs
am654_sdhci mmc@fa10000: Couldn't find 
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr12
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr25
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr50
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-ddr50
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-sdr104
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-hs200
am654_sdhci mmc@fa10000: Couldn't find ti,otap-del-sel-hs400
before am654_sdhci init:
phy_ctrl1 0x00010023, phy_ctrl2 0x00000000, phy_ctrl3 0x10ff30ff
phy_ctrl4 0x00106103, phy_ctrl5 0x00000407, phy_ctrl6 0x00000000

after sdhci SDHCI_RESET_ALL:
phy_ctrl1 0x00010023, phy_ctrl2 0x00000000, phy_ctrl3 0x10ff30ff
phy_ctrl4 0x00000103, phy_ctrl5 0x00000407, phy_ctrl6 0x00000000

PHY_CTRL1 0x00010023, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00000103, PHY_CTRL5 0x00000407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

clock is disabled (0Hz)
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

selecting mode MMC legacy (freq : 0 MHz)
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x00

clock is enabled (400000Hz)
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

CMD_SEND:0
		ARG			 0x00000000
		MMC_RSP_NONE
CMD_SEND:8
		ARG			 0x000000aa
		RET			 -110
CMD_SEND:55
		ARG			 0x00000000
		RET			 -110
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x0, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

CMD_SEND:0
		ARG			 0x00000000
		MMC_RSP_NONE
CMD_SEND:1
		ARG			 0x00000000
		MMC_RSP_R3,4		 0x00ff8080 
CMD_SEND:1
		ARG			 0x40000080
		MMC_RSP_R3,4		 0x00ff8080 
CMD_SEND:1
		ARG			 0x40000080
		MMC_RSP_R3,4		 0xc0ff8080 
___ pass failure point
CMD_SEND:2
		ARG			 0x00000000
		MMC_RSP_R2		 0x13014e53 
		          		 0x304a3536 
		          		 0x581031fb 
		          		 0xdcdc5900 

					DUMPING DATA
					000 - 13 01 4e 53 
					004 - 30 4a 35 36 
					008 - 58 10 31 fb 
					012 - dc dc 59 00 
CMD_SEND:3
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000500 
CMD_SEND:9
		ARG			 0x00010000
		MMC_RSP_R2		 0xd07f0132 
		          		 0x8f5903ff 
		          		 0xc003ffef 
		          		 0x86400000 

					DUMPING DATA
					000 - d0 7f 01 32 
					004 - 8f 59 03 ff 
					008 - c0 03 ff ef 
					012 - 86 40 00 00 
selecting mode MMC legacy (freq : 25 MHz)
CMD_SEND:7
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000700 
CMD_SEND:8
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000900 
mmc: widths [8, 4, 1, ] modes [MMC legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz), HS200 (200MHz), HS400 (200MHz), ]
host: widths [8, 4, 1, ] modes [MMC legacy, MMC High Speed (26MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz), ]
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x18, HOST_CONTROL2 0x00, CLOCK_CONTROL 0xfa07

clock is enabled (25000000Hz)
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x18, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x407

trying mode MMC DDR52 (52MHz) width 8 (at 52 MHz)
CMD_SEND:6
		ARG			 0x03b70200
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
CMD_SEND:6
		ARG			 0x03b90100
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
CMD_SEND:6
		ARG			 0x03b70600
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
selecting mode MMC DDR52 (52MHz) (freq : 52 MHz)
PHY_CTRL1 0x00010021, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00100110, PHY_CTRL5 0x00030407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x38, HOST_CONTROL2 0x00, CLOCK_CONTROL 0x407

clock is enabled (52000000Hz)
PHY_CTRL1 0x00010023, PHY_CTRL2 0x00000000, PHY_CTRL3 0x10ff30ff
PHY_CTRL4 0x00106103, PHY_CTRL5 0x00000407, PHY_CTRL6 0x00000000
HOST_CONTROL 0x3c, HOST_CONTROL2 0x04, CLOCK_CONTROL 0x207

CMD_SEND:8
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:6
		ARG			 0x03b34900
		MMC_RSP_R1b		 0x00000800 
CMD_SEND:13
		ARG			 0x00010000
		MMC_RSP_R1,5,6,7 	 0x00000900 
CURR STATE:4
spl: mmc boot mode: raw
CMD_SEND:17
		ARG			 0x00001800
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:18
		ARG			 0x00001800
		MMC_RSP_R1,5,6,7 	 0x00000900 
CMD_SEND:12
		ARG			 0x00000000
		MMC_RSP_R1,5,6,7 	 0x00000b00 
Authentication passed
Authentication passed


U-Boot 2024.04-ti-g29d0c23d67ee (Nov 29 2024 - 11:41:54 +0000)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-EVM rev C
DRAM:  2 GiB
Core:  98 devices, 31 uclasses, devicetree: separate
NAND:  0 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
Hit any key to stop autoboot:  2  0 
=>

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Hi David,

    Attached below are 2 more U-Boot debug patches, in addition to the 3 in my previous post above.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0005_2D00_mmc_2D00_dump_2D00_sdhci_2D00_registers_2D00_in_2D00_am654_5F00_sdhci.patch

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0006_2D00_mmc_2D00_dump_2D00_pll0_2D00_and_2D00_pll2_2D00_registers.patch

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Hi David,

    Here are two more debug patches, to dump more registers right after CMD1 failed.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0007_2D00_mmc_2D00_remove_2D00_pll2_2D00_register_2D00_dump.patch

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0008_2D00_mmc_2D00_dump_2D00_all_2D00_mmc_2D00_registers.patch

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    One more U-Boot patch to dump the mmc registers at the beginning of each U-Boot stage.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0009_2D00_mmc_2D00_dump_2D00_all_2D00_register_2D00_before_2D00_bus_2D00_clk_2D00_set_2D00_to_2D00_0hz.patch

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    After reviewed the U-Boot source used in your project with the U-Boot source in SDK10.1, I found your U-Boot misses a very important patch in the K3 PLL driver (drivers/clk/ti/clk-k3-pll.c):

    fda88f8bcea3 ("clk: ti: clk-k3-pll: Add additional robustness steps to the PLL sequence")

    The patch itself won't tell if missing it is the root cause of the eMMC issue, but it is high recommended to apply this patch to ensure the PLL is configured properly.

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Sorry, false alarm.

    The driver clk-k3-pll.c is only for other AM6xx processors, but not applicable to AM64x. So it is okay to not have this patch in your project.

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Hi Will,

    The AM64x register which latches the bootmode is MAIN_DEVSTAT (address 0x43000030). Its bit 0-15 map to BOOTMODE pins in AM64x TRM (rev I) section 4.3.1 ("BOOTMODE pin mapping).

    I typically set this register to 0x243 for SDcard boot. I don't typically use eMMC UDA boot, so I don't have its value at the moment.

    The register which triggers SW warm-reset or SW POR is RST_CTRL (address 0x43018170). You already use it in U-Boot function hang().

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Hi Will,

    Attached below is the u-boot patch for the test we want you to run on a system on which the problem is expected to happen after reboot. The patch limits the eMMC speed to 25MHz in the entire U-Boot life cycle. 

    The change in the patch assumes you have already removed the "ti,otap-del-sel-hs200" entry, so that only "ti,otap-del-sel-legacy" is in the sdhci0 node.

    With DEBUG set in drivers/mmc/mmc.c, you would see the U-Boot console log only has

        clock is enabled (25000000Hz)

    not any other higher frequencies.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0010_2D00_mmc_2D00_limit_2D00_eMMC_2D00_to_2D00_legacy_2D00_mode_2D00_25MHz.patch

  • 0 in reply to Bin Liu
    TI__Guru**** 179926 points

    Hi Will,

    Do you have any update on this test?

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Hi Bin,

    You can ignore the report that I provided a couple of days ago. There was an unrelated issue that prevented that board from booting as expected.

    Yesterday, I was able to boot an image with the latest patch on a board that appeared to exhibit the problem. The board got stuck as before & recovered on a power cycle :

    U-Boot SPL 2024.04-ti-g0623014d0ace (Feb 17 2026 - 15:38:12 +0000)
R5 Hardware, booted from 'primary' partition
Reset Source: SW_MCU_WARMRST
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121
SPL initial stack usage: 13400 bytes
Trying to boot from MMC1
spl_mmc_load: 0 2048
spl_mmc_load: mcc dev 0
clock is disabled (0Hz)
clock is enabled (400000Hz)
mmc_get_op_cond: uhs_en=0, -110
clock is enabled (25000000Hz)
clock is enabled (25000000Hz)
spl_mmc_load: spl_mmc_boot_mode 3
spl: MMCSD_MODE_EMMCBOOT
spl: mmc boot mode: raw
spl_mmc_load: raw_sect got set to 2048
spl_mmc_load: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
mmc_pol_check_fit_hash: checking hash of fit image; fit_image 0x81e01340, fit_length 962595...
mmc_load_image_raw_sector: loading fit image from primary partition
_spl_load: reading from offset 0x100000
_spl_load: header magic FDT_MAGIC
## Checking hash(es) for config conf-0 ... OK
## Checking hash(es) for Image atf ... OK
## Checking hash(es) for Image tee ... OK
## Checking hash(es) for Image dm ... OK
## Checking hash(es) for Image spl ... OK
Authentication passed
## Checking hash(es) for Image fdt-0 ... OK
Authentication passed
_spl_load: simple_fit returned 0
Loading Environment from nowhere... OK
init_env from device 9 not supported!
jump_to_image_no_args: Authenticating image: addr=701c0000, size=54644, os=arm-trusted-firmware
Authentication passed
jump_to_image_no_args: Authenticating image: addr=9e800000, size=660404, os=tee
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.11.0(release):v2.11.0-906-g58b25570c9-dirty
NOTICE:  BL31: Built : 04:20:32, Nov  1 2024
I/TC:
I/TC: OP-TEE version: 4.1.0-2-gbfcdcd35c-dev (gcc version 13.3.0 (GCC)) #1 Tue May 20 13:26:54 UTC 2025 aarch64
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-ti-g0623014d0ace (Feb 17 2026 - 15:38:12 +0000)
A53 Hardware
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121
Trying to boot from MMC1
spl_mmc_load: 0 6144
spl_mmc_load: mcc dev 0
clock is disabled (0Hz)
clock is enabled (400000Hz)
mmc_get_op_cond: uhs_en=0, -110
mmc_get_op_cond:mmc_send_op_cond() -110
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
### Forcing COLD RESET ###

    Please let me know if you have any questions or suggestions.

  • 0 in reply to Will Frazer
    TI__Guru**** 179926 points

    Hi Will,

    Thanks for the update.

    The log shows the MMC bus only runs up to 25MHz, so DLL is not relevant to the issue.