[参考译文] AM4379：AM4379

已将查询分配给专家。 请在1天或2天内收到回复。

谢谢！

1.接受测试的器件为定制电路板。

2.它基于  ARM Cortex-A9 内核。

3. Linux 是运行在处理器核心上的操作系统。

未使用 TI 处理器 SDK。

5.硬件设置是用于获取启动日志的串行通信调试端口。

6.希望在开机时启动。

7.相反、启动过程未完成、调试日志显示它显示"正在尝试从 MMC 引导"

8、这是我们第一次只在一个电路板上看到此问题。

9.每次启动时出现问题。

10.我们为 MMC 执行了 ABA 交换、但失败不会跟随 MMC。

11.下面粘贴了故障电路板和已知良好电路板的启动日志：

CCCCCCCCCC
U-Boot SPL 2016.03 (2019年12月24日- 17：33：35)
MC-X1 1.17
尝试从 MMC 引导

CCCCCCCCCC
U-Boot SPL 2016.03 (2019年12月24日- 17：33：35)
MC-X1 1.17
尝试从 MMC 引导

U-Boot 2016.03 (2019年12月24日- 17：33：35 + 1000)
MC-X1 1.17

I2C：就绪
DRAM：1GiB
MMC：OMAP SD/MMC：0、OMAP SD/MMC：1.
网络：cpsw

欢迎观看 MCX1

自动引导1秒后、按 ESC 两次以取消
正在检查固件
引导固件1.
##从 FIT Image 加载内核83000000 ...
使用"CONFIG@1"配置
正在尝试"kernel@1"内核子映像
描述：4.4.245+git0+565c417795-r0-mcx1-20220121043537
键入：Kernel Image
压缩：未压缩
数据启动：0x830000e4
数据大小：2969696字节= 2.8 MIB
架构：arm
操作系统：Linux
载入地址：0x82000000
入口点：0x82000000
哈希算法：CRC32
哈希值：3b6ef755
正在验证散列完整性... CRC32+确定
##从 FIT Image 加载 RAMDISK at 83000000 ...
使用"CONFIG@1"配置
正在尝试"ramdisk@1" ramdisk 子镜像
说明：rootfs
类型：ramdisk Image
压缩：未压缩
数据启动：0x832e075c
数据大小：18365051字节=17.5 MIB
架构：arm
操作系统：Linux
载入地址：0x00000000
入口点：0x00000000
哈希算法：CRC32
散列值：82d6db71
正在验证散列完整性... CRC32+确定
##在83000000处从 FIT Image 加载 FDT ...
使用"CONFIG@1"配置
正在尝试"FDT@1" FDT 子映像
描述：4.4.245+git0+565c417795-r0-mcx1-20220121043537
类型：扁平设备树
压缩：未压缩
数据启动：0x832d523c
数据大小：46206字节= 45.1kiB
架构：arm
哈希算法：CRC32
哈希值：ccda0f1d
正在验证散列完整性... CRC32+确定
使用0x832d523c 处的 FDT blob 进行引导
正在加载内核映像...确定
正在将 Ramdisk 加载到8ee7c000,结束8ffa7b...确定
正在将设备树加载到8ee6d000,结束8ee7b47d...确定

正在启动内核...

您好、Oleh：

感谢您提供详细信息。

控制台日志显示 ROM 能够从 MMC 读取第一个引导加载程序(MLO)并执行它、但 MLO 无法从 MMC 读取第二个引导加载程序(u-boot.img)。

Unknown 说：

我正在引发字段返回、故障症状是"正在尝试从 MMC 引导"。

由于这是现场返回、因此我怀疑硬件可能会损坏、从而导致出现问题。 我会将您的问题发送给我们的硬件团队进行评论。

有多少系统遇到此问题？

您是否确认任一器件的信号质量良好、信号时序均未违反？

此致、
Paul