[参考译文] AM6442：间歇性 eMMC 引导问题

由于星期一是 TI 美国度假、回复可能会延迟。  

请继续分享上述建议后续行动项目中的任何其他相关信息。  

客户正在调查这一问题、以查看是否存在潜在的 I2C 挂起问题以及后续的引导失败

我们已经检查了 I2C、可以说根据进一步的测试、I2C 消息是良性的。 由于正在探测不存在的设备、因此会报告此错误。 我们还确认、使用示波器电气 SDA 正常工作。 为了检查是否可能出现引导挂起、我们强制 SDA 发生短路、并通过以下额外消息确认引导正常完成：

客户还会检查从 AM644x 到 eMMC

我们还查看了进入 eMMC 的复位、时序看起来正常、测量值为 158uS。

我们对这个问题很好奇

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

这听起来是相关的,并希望在我们目前的 eMMC 问题的背景下发表评论。

eMMC 传统模式似乎有效、因此正在研究其性能影响。

目前正在进行中。

谢谢你。

尊敬的 Will：

感谢您的更新。

我们还研究了进入 eMMC 的复位、时间看起来正常、测量值为 158uS。

我查看了提供的故障引导日志、认为问题与 eMMC 复位无关。 日志显示 ROM 能够从 eMMC 加载/运行 R5 SPL (tiboot3.bin)、R5 SPL 也能够从 eMMC 加载/运行 A53 SPL (tispl.bin)、然后当 A53 SPL 尝试加载 A53 U-Boot (u-boot.img) 时会发生 eMMC 故障。 eMMC 似乎可以正常读取 tiboot3.bin 和 tispl.bin、因此似乎可以通过热复位信号正确复位。

eMMC 传统模式似乎有效、因此正在研究其性能影响。

您能否展示用于将 eMMC 配置为传统模式的 U-Boot 补丁？

引导日志显示 SYSFW 版本 v10.1.8、是否使用 AM64x SDK v10.1 的 U-Boot？ SDK11.2 中有一些 U-Boot MMC 驱动程序更新、这些更新与 MMC 时序相关、我需要检查这些补丁是否应该移植到 SDK10.1 U-Boot 中以便您进行测试。

感谢您的更新。

您能否展示用于将 eMMC 配置为传统模式的 U-Boot 补丁？

目前我们没有强制采用此模式。 即、我们认为、当 eMMC 复位时、它会在此模式下启动、并且鉴于在我们获得超时之前它似乎是可读的、我们认为旧模式显然没有出现问题。 我们的后续意图是强制 eMMC 保持在这种模式下、而不是尝试使用更快的模式来查看问题是否仍然发生、以及内核代码是否能够更好地处理 eMMC 状态。 当我们有一个强制此模式的补丁时、我可以分享、但理想情况下、这将用于测试目的、至少在最初。

引导日志显示 SYSFW 版本 v10.1.8、是否使用 AM64x SDK v10.1 的 U-Boot？

我们的 U-Boot 源代码日期从 2024 年开始、我相信 SDK v10.1 也会这样做、但我需要比较基线以了解对齐情况。 我当然有兴趣详细了解 SDK11.2 更新、特别是与 MMC 时序相关的更新。 谢谢。

尊敬的 Will：

当我们有一个补丁来强制使用这种模式时、我可以在理想的情况下共享这种模式、至少在最初是为了测试目的。

我同意强制使用传统模式不能解决问题。 因此、这项工作的优先级应该较低。

我当然有兴趣了解更多有关 SDK11.2 更新的信息、特别是与 MMC 时序相关的信息。

快速检查 U-Boot、自从 SDK v10.1 发布标签以来、AM62x MMC 控制器驱动程序有 18 个补丁。

TI-u-boot.git$ glog 10.01.10... drivers/MMC/am654_sdhci.c
0fea7f943734 FROMLIST：mmc：am654_sdhci：禁用适用于 AM62P SR1.0 和 SR1.1 的 HS400
98b6b3f5a259（标签：cicd.scarthgap.202505151402、标签：11.00.13）待定：mmc：am654_sdhci：清除 UHS_MODE_SELECT
ee6c46a606bf FROMLIST：mmc：am654_sdhci：添加 am654_sdhci_set_control_reg
cd91d7360181（标签：cicd.scarthgap.201503251551、标签：11.00.09）待定：mmc：am654_sdhci：取消设置 MMC_HS_52 的 high_speed_ENA
804035fae6ea 待处理：mmc：am654_sdhci：将 MMC_HS_52 添加到计时数据
36e384d4eef5 待定：MMC：am654_sdhci：为 SDR12 和 SDR25 设置 HIGH_SPEED_ENA
f2be440ceb3c 待定：mmc：am654_sdhci：修复可能的 NULL derref
afdce7686371 MMC：am654_sdhci：添加 quirk 以设置 TESTCD 位
03de305ec48b 恢复补丁系列“arm：dts：am62-beagleplay：修复 Beagleplay 以太网“
d678a59d2d71 恢复“合并补丁系列“arm：dts：am62-beagleplay：修复 Beagleplay 以太网“
7938ac657ba6 MMC：删除 并添加所需的包括项
2143a11e6149 MMC：将 MMC_support_tuning 迁移到 Kconfig
f13a830e6e4a MMC：am654_sdhci：修复 HS400 时序的 ITAPDLY
a124e31a97cd mmc：am654_sdhci：对于 DDR52 模式、设置 ENDLL=1
056af04a39ae MMC：am654_sdhci：添加 Itap_del_ena[]以存储 itapdlyena 位
5048b5c61afd MMC：am654_sdhci：修复 OTAP/ITAP 延迟值
6b8dd9ca6e06 MMC：am654_sdhci：添加延迟链的调优算法
a3b2786651c7 MMC:丢弃未使用的 MMC_send_tuning() cmd_error 参数

您是否认为只编译 SDK11.02 U-Boot 代码库并在电路板上对其进行测试、而不是识别要向后端口的补丁？

尊敬的 Bin Liu：

我们将查看补丁程序列表、谢谢。

在设计中、我们有一个 LP8733 PMIC 并尝试执行 SW_RESET 来对 eMMC 进行下电上电、但是 SW_RESET 命令似乎已切断 PMIC 输出的电源、但没有重新启用它们、因此系统不会重新启动。 如果鼓励 PMIC 执行我们需要的操作、这可能是退出复位环路并从问题中恢复的可行方法。

以前、我链接了另一个 E2E 工单、想知道您是否看到了该工单、以及您是否认为这与我们看到的内容有关。  

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

尊敬的 Will：  

LP8733 PMIC 的软件复位更像是冷复位、可以触发断电序列并关闭所有稳压器。 PMIC 没有仅切换 PGOOD/PORz 的 I2C 命令。  

谢谢、

Brenda

尊敬的 Will：  

关于您参考的主题、我们认为这可能是一个可能的原因。  它是指 eMMC 主机控制器可能会进入重新初始化（即尝试初始化已经初始化的控制器）失败的状态、唯一恢复方法是对 eMMC 主机控制器断电（或复位）以使其恢复到上电状态。  这是通过 LPSC（本地电源/睡眠控制器）完成的。  

一个可能的实验是获取您拥有的故障电路板并重置主机控制器、但这只能通过 JTAG 完成。  您是否有 JTAG 访问权限？   

借助 JTAG 访问、我们还可以尝试转储 eMMC 控制器寄存器、以查看它处于什么状态。   

此致、

James

您好、James：

感谢您的答复。

遗憾的是、出于安全原因、JTAG 已从电路板中移除。

感谢 Brenda、这与我们进行的测试保持一致。

今天的电话中我的行动项目是描述我的建议、即在不循环通电的情况下断言系统的冷复位。

我最初误解了您尝试使用 PMIC I2C 命令执行的操作。 我想您正尝试将处理器 MCU_PORz 复位输入置为有效、以查看系统是否在没有下电上电的情况下恢复。

现在、我知道您希望 I2C 命令能够对 eMMC 器件进行下电上电、其中 PMIC 会对电源轨进行下电时序控制、然后进行上电序列。 正如 Brenda 所述、您发送的 I2C 命令只会导致断电序列。

你可能想考虑我认为你试图做的测试。  如果我们在不循环通电的情况下将 MCU_PORz 置为有效、从而查看故障系统是否 仅从 冷复位中恢复、这可能有助于我们了解发生了什么情况。  由于 MCU_PORz 的置位会使处理器中的每个电路复位、因此我预计下电上电与不循环下电的冷复位置位之间不会有任何差异。  当您将热复位置为有效时、情况并非如此。

 由于 MCU_PORz 信号输出为开漏输出、因此可以从连接到 PMIC 复位输出的外部源将其拉至低电平。 外部源需要产生具有适当 最小脉 冲持续时间的低电平脉冲、以确保不违反处理器脉冲宽度要求。 该 1200ns 最小脉冲宽度参数在数据表 MCU_PORz 时序要求表中定义为 RST3。

如上所述、我期望冷复位产生与下电上电相同的结果。  因此、如果您对需要很长时间才能进入 故障状态的系统进行了更富有成效的测试、则可能需要推迟此测试。

此致、
Paul

上周与 Brenda 谈话时出现了一些混乱、我之前回复的部分内容不正确。 她 看到我对 E2E 的回复、并于今天上午发送了一封私人电子邮件、说明 LP8733 PMIC 的工作原理。

Brenda 确认设置 SW_RESET 位 将启动 断电 序列、然后启动上电序列。 她还确认、如果不进行下电上电、无法切换 PMIC 复位输出。

此致、
Paul

尊敬的 Will：

我知道 eMMC 锁定问题最初是在 eMMC 上更新系统固件后在现场报告的、但您是否曾在不更新 eMMC 上的固件的情况下重现该问题？ 我正在尝试了解该问题是否与固件更新过程中的 eMMC 写入事务有关。

我收到离线响应、确认发现问题、但未更新 eMMC 上的固件。

尊敬的 Will：

为了继续讨论我们在今天的会议中讨论的 PMIC 断电/上电主题、您能否提供测试程序的详细信息、以触发电路板上 PIMC 的软件复位？ 例如、您是直接在 Linux 中使用 i2c 命令来访问 PMIC 寄存器、还是使用任何具有 i2c 传输到幕后实现的 PMIC 的 Linux 命令？

嗨、Bin Lui。

我们使用 Linux 的 i2c。

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

Michael Leitzgen 独立尝试了相同的命令以及等效的 U-Boot。

您好、David：

附件是我当前用于在 AM64x EVM 上转储 eMMC 调试日志的 SDK 10.1 U-Boot 补丁。

e2e.ti.com/.../0002_2D00_dts_2D00_am64x_2D00_disable_2D00_eMMC_2D00_hs200.patch

e2e.ti.com/.../0003_2D00_configs_2D00_am64x_2D00_enable_2D00_eMMC_2D00_trace_2D00_and_2D00_debug.patch

e2e.ti.com/.../0004_2D00_mmc_2D00_dump_2D00_mmc_2D00_registers.patch

下面随附了控制台调试日志以供您参考。

e2e.ti.com/.../am64x_2D00_emmc_2D00_trace_2D00_0211_2D00_sdk101.log

您好、David：

下面附加了另外 2 个 U-Boot 调试补丁、此外还有上面我上一篇文章中的 3 个补丁。

e2e.ti.com/.../0005_2D00_mmc_2D00_dump_2D00_sdhci_2D00_registers_2D00_in_2D00_am654_5F00_sdhci.patch

e2e.ti.com/.../0006_2D00_mmc_2D00_dump_2D00_pll0_2D00_and_2D00_pll2_2D00_registers.patch

您好、David：

这里还有另外两个调试补丁、用于在 CMD1 失败后立即转储更多寄存器。

e2e.ti.com/.../0007_2D00_mmc_2D00_remove_2D00_pll2_2D00_register_2D00_dump.patch

e2e.ti.com/.../0008_2D00_mmc_2D00_dump_2D00_all_2D00_mmc_2D00_registers.patch

还有一个 U-Boot 补丁、用于在每个 U-Boot 阶段开始时转储 MMC 寄存器。

e2e.ti.com/.../0009_2D00_mmc_2D00_dump_2D00_all_2D00_register_2D00_before_2D00_bus_2D00_clk_2D00_set_2D00_to_2D00_0hz.patch

在使用 SDK10.1 中的 U-Boot 源查看了您工程中使用的 U-Boot 源后、我发现您的 U-Boot 未命中 K3 PLL 驱动程序中的一个非常重要的补丁 (drivers/clk/ti/clk-k3-pll.c)：

fda88f8bcea3 （“clk：TI：CLK-k3-PLL：为 PLL 序列添加额外的稳健性步骤“）

补丁本身不会判断是否缺失、这是 eMMC 问题的根本原因、但强烈建议应用该补丁以确保正确配置 PLL。

抱歉、误报。

驱动程序 clk-k3-pll.c 仅适用于其他 AM6xx 处理器、但不适用于 AM64x。 因此、您的工程中没有这个补丁是可以的。

尊敬的 Will：

锁存引导模式的 AM64x 寄存器为 MAIN_DEVSTAT（地址 0x43000030）。 它的位 0-15 映射到 AM64x TRM（修订版 I）第 4.3.1 节（“BOOTMODE 引脚映射）中的 BOOTMODE 引脚。

我通常将该寄存器设置为 0x243 以进行 SD 卡引导。 我通常不使用 eMMC UDA 引导、因此目前没有它的值。

触发 SW 热复位或 SW POR 的寄存器是 RST_CTRL（地址 0x43018170）。 您已经在 U-Boot 函数 hang() 中使用了它。

尊敬的 Will：

下面随附了我们希望您在系统上运行的测试的 u-boot 补丁程序、该系统在重新引导后预计会出现问题。 该补丁在整个 U-Boot 生命周期中将 eMMC 速度限制为 25MHz。  

补丁中的更改假设您已删除“ti、otap-del-sel-HS200“条目、因此 sdhci0 节点中只有“ti、otap-del-sel-legacy“。

在 drivers/MMC/MMC.c 中设置了调试设置后、您会看到 U-Boot 控制台日志只具有

  时钟已启用 (25000000Hz)

而不是任何其他较高的频率。

e2e.ti.com/.../0010_2D00_mmc_2D00_limit_2D00_eMMC_2D00_to_2D00_legacy_2D00_mode_2D00_25MHz．patch

尊敬的 Will：

您对此测试有任何更新吗？

尊敬的 Bin：

您可以忽略我几天前提供的报告。 存在一个无关的问题、导致该电路板无法按预期启动。

昨天、我在主板上使用最新补丁启动了一个映像、该映像似乎出现了问题。 电路板像以前一样卡滞并在电源循环中恢复：

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 ###

如果您有任何问题或建议、请告诉我。