[参考译文] AM620-Q1：使用 TI SysConfig 工具的 DDR 配置

Shibi、即使您使用同一个 LPDDR4 器件、定制电路板设计可能也需要不同的配置设置。  对于您的定制设计、驱动强度和端接设置等一些 IO 配置可能需要不同。  您是否执行了任何板级仿真以确定哪些设置可以提供出色的信号完整性？

您能否提供有关哪些测试运行失败的更多详细信息？

您得到了哪个 SDK 版本的 k3-am62-lp4-50-800-800.dtsi？  如果从 v11.x 获得、则 DDR 配置与 SBL 相同、因此您应该不会从 DDR 的角度看到任何不同的运行情况。

此致、

James

您指的是 MCU+SDK 或处理器？ 我会回到你的模拟细节..

如果您有任何可用于测试的 DDR 工具、请分享详细信息。

SBL 处理来自 SPL 的 RAM 初始化的方式有何不同？ 有什么需要查看源代码的吗？

SBL 和 SPL 的初始化过程没有差异、除非配置文件存在差异。  这就是我要求 SBL 和 SPL 的配置文件是否存在差异的原因。   

此致、

James

e2e.ti.com/.../k3_2D00_am62x_2D00_ddr_2D00_config.txte2e.ti.com/.../6052.board_5F00_lpddrReginit.h

共享了使用 Sysconfig 0.10.32 生成的两个文件。 未观察到差异。 我使用的是 MCU PLUS SDK  11.00.00.16.

Shibi、  

您之前说过 “一些测试失败“ 。  您能否提供完整的日志、说明您正在运行哪些测试失败？  此外、有多少百分比的电路板发生了这种故障？  您是否对失败的电路板具有 JTAG 访问权限并可以运行 Code Composer？

我想全面了解测试过程中涉及的元件、因为此时我不确定我们是否涉及 DDR

此致、

James

我们在 80%的器件上看到此问题。

“某些测试失败“消息是由于 M4F 应用映像身份验证失败。 它在此时停止并返回错误。 在进行身份验证并加载到 CPU 之前、应用映像从 NOR 闪存复制到 RAM。 我通过写和读回添加了手动 RAM 测试。 我可以看到所有存储器位置都发生了数据不匹配。

SYSFW 固件版本 11.1.2--v11.01.02 (Fancy Rat)
SYSFW 固件版本 0xb
SYSFW ABI 修订版 4.0

执行 ram 测试
错误：RAM_TEST：275：84000000 索引 0 数据 0x0 处的数据不匹配
错误：RAM_TEST：275：84000004 索引 1 数据 0x0 处的数据不匹配
错误：RAM_TEST：275：84000008 索引 2 数据 0xBE000000 处的数据不匹配
错误：RAM_TEST：275：8400000C 索引 3 数据 0xFEEFFEEF 处的数据不匹配
错误：RAM_TEST：275：84000010 索引 4 数据 0xFE00FE00 处的数据不匹配
错误：RAM_TEST：275：84000014 索引 5 数据 0xFE00FE00 处的数据不匹配
错误：RAM_TEST：275：84000018 索引 6 数据 0xFEEFFEF 处的数据不匹配
错误：RAM_TEST：275：8400001C 索引 7 数据 0xFE00FE00 处的数据不匹配
错误：RAM_TEST：275：84000020 索引 8 数据 0x0 处的数据不匹配
错误：RAM_TEST：275：84000024 索引 9 数据 0x0 处的数据不匹配

谢谢 Shibi、

20%的工作电路板是否总是正常工作？  同样、发生故障的 80%电路板是否总是出现故障？  或者是否有董事会有时通过、有时失败的情况？

您是否启用了 DDR ECC？ 如果是、请立即禁用 ECC、直到我们通过此调试。

那么、您认为此故障是首次读取 DDR 的结果吗？  我只是想了解 DDR 是否在最初工作、然后损坏、或者从一开始它是否从未处于良好状态。

以下是一些进一步的步骤：

看到测试失败后、您是否可以使用附加的 GEL 脚本执行 DDR 寄存器转储

 /cfs-file/__key/communityserver-discussions-components-files/791/DDRSS_5F00_RegDump.gel 并发布结果。

如果您可以得到一个未出现故障的电路板、那么从中获得 regdump 也会很好、这样我可以进行比较。   

此致、

James

您好、James：

    20%的器件始终表现出此行为。 其他器件在一些下电上电期间也显示了这种行为。 默认情况下禁用 ECC。 它从一开始就处于不正确的状态。  

我将很快分享 DDR 寄存器详细信息。

连接从工作板而不是工作板获取的寄存器转储。

您可以发现很多不匹配情况。

e2e.ti.com/.../failing_5F00_board.txte2e.ti.com/.../3264.working_5F00_board.txt

尊敬的 Shibi：

我比较了两个文件、大多数错误来自在初始化阶段发生变化的只读位。

但是,奇怪的是,在初始化过程中应该写入的参数很少,并且永远不会更改,但是它们与工作版本不同。  请参阅以下示例：

我以前从未见过这种行为。  此外、我不确定初始化失败时受影响的参数是否总是错误的参数、或者问题是否更随机。  您能否从失败的引导中再获取几个寄存器转储、看看这些参数是否仍然存在问题、或者问题是否更普遍？   

至于现在、这就是没有正确初始化 DDR 的原因。  一种可能的权变措施是执行某种类型的 DDR 寄存器写入验证（即，回读和验证每个寄存器）

此致、

James

您能否从失败的引导中再获取几个寄存器转储、看看这些参数是否仍然存在问题、或者问题是否更普遍？   [/报价]

为工作板和非工作板添加更多日志  

命名约定 _<板数>_<其中的测试迭代>

电路板状态基本上正常或无法正常工作  

您能否从失败的引导中再获取几个寄存器转储、看看这些参数是否仍然存在问题、或者问题是否更普遍？   [/报价]

为工作板和非工作板添加更多日志  

命名约定 _<板数>_<其中的测试迭代>

电路板状态基本上正常或无法正常工作  

我在每次迭代中都能看到工作板的不同

e2e.ti.com/.../non_5F00_working_5F00_1_5F00_1.txte2e.ti.com/.../non_5F00_working_5F00_1_5F00_2.txte2e.ti.com/.../non_5F00_working_5F00_2_5F00_3.txte2e.ti.com/.../working_5F00_board_5F00_1_5F00_1.txte2e.ti.com/.../working_5F00_board_5F00_1_5F00_2.txte2e.ti.com/.../working_5F00_board_5F00_1_5F00_3.txte2e.ti.com/.../non_5F00_working_5F00_1_5F00_3.txte2e.ti.com/.../non_5F00_working_5F00_2_5F00_1.txte2e.ti.com/.../non_5F00_working_5F00_2_5F00_2.txt

我检查了几个不工作的转储（从不同的板）,他们显示类似的症状。  只是少数寄存器没有正确写入（有些寄存器显示相同的寄存器，但板对板，故障寄存器略有不同）

这正促使我认为驱动 IP 寄存器接口的接口时钟存在根本错误。  但为什么会发生这种情况、我不确定。 请给我一些时间来研究一下。

此致、

James   

作为一个实验、您能否在 CTL PI 和 PHY 寄存器的 DDR 寄存器初始化循环期间添加验证检查？  这将有助于了解问题是随机发生一次、还是在某些电路板上仍然存在。

此致、

James

1.我在每次 ctl PI 和 PHY 写入后都尝试调用 LPDDR4_VerifyRegWrite 、并且它成功并返回  

cdn_eok、表示成功。 然而,我无法在这里获取日志,因为这是发生的时候 UART 没有启动,我无法获取日志.

2.回答你的第二个问题,这是我有意只是为了让我知道它是什么阶段失败,即使在工作板我会得到类似的日志如下所示。

SYSFW 固件版本 11.1.2--v11.01.02 (Fancy Rat)
SYSFW 固件版本 0xb
SYSFW ABI 修订版 4.0

从加载映像
[bootloader_profile]引导介质：闪存
[bootloader_profile]引导介质时钟：166.667MHz
[bootloader_profile]引导映像大小：214 KB
[bootloader_profile]存在内核：
m4f0-0
r5f0-0
[bootloader profile] System_init：29221us
【引导加载程序配置文件】Board_init：0us
[bootloader profile] Drivers_open : 207us
【引导加载程序配置文件】Board_drivers 打开：120US
[bootloader profile] Sciclient 获取版本：10204us
[bootloader profile] App_waitForMcuPbist：101us
[bootloader profile] App_waitForMcuLbist : 7689us
[bootloader profile] App_loadImages：10053us
[bootloader profile] App_loadSelfcoreImage : 11129us
[bootloader_profile] SBL 总用时：68728us

图像加载完成、切换到应用程序...
启动 MCU-M4F 和第二阶段引导加载程序

3. 此外,我观察到某些寄存器在多个实例运行期间发生了变化。 你能提供更多的信息,哪些寄存器应该保持不变,也很少的信息,你怀疑哪些寄存器出来不同于工作板可能会导致问题这里.

该问题的硬件信号完整性方面的快速更新。  我们的硬件 1 级对 LPDDR4 进行了 Shmoo 测试、结果良好。  这是使用我认为的 TI DDR 裕度固件完成的。  

初始化后将有几个寄存器会发生变化、其中大多数寄存器是状态/观察参数、或其他参数（如与训练相关的参数）、预计会发生变化。  我上面提到的情况不会发生变化、因此您可以先检查这些情况。   

我有点困惑你的评论 2 ) 以上。  您是否在不同的启动阶段失败？  根据我看到的内容、电路板发生故障时 DDR 未正确初始化、因此故障应在同一引导阶段发生（即 SBL 首次访问 DDR）。  如果您在不同的引导阶段失败、这是另一个问题。

如果该验证函数返回成功、那么我期望正确初始化 DDR。  验证功能是否失败？

此致、

James

您好、James：   

    感谢您的推荐。 它是有效的。

查看源代码、添加此代码似乎是为了进行调试。 在我们这边取消定义 DDR_PLL_RESET 是好吗？

#define DDR_PLL_RESET

#if defined (DDR_PLL_RESET)

/*这是一段代码、用于将 DDR PLL 复位为 GEL 可配置值
有助于避免 DDR PLL 在热复位后进入不良配置。
这是一个临时修复、实际修复涉及 SCI 客户端直接库的更改
*/

谢谢、

Shibi

您好、James：  

针对此问题快速跟进几个问题、以确保我们完全了解权变措施：

1.)  长期解决方案是否会删除 SDK 中的这一行代码？

2.) 如果这是一致的软件问题、为什么它 在使用相同 RAM 的 EVK 上不可重复？

3.) 删除这行代码有什么影响（如果有）？ 周围的评论使它看起来很重要。  

提前感谢您提供的额外帮助！  

此致、

Luke

您好、Luke、

James 不在时间银行、我会询问软件团队该代码区域的长期状态/影响。

此致、

Lucas

您好、Lucas：

您是否收到了 SW 团队关于这一个的任何反馈？

此致、

Luke

您好、Luke、

软件团队表示、将在将来的版本中审查修复的必要性、并在测试后删除（如果不需要）。 同时、您可以取消定义宏、但他们建议针对您的平台的热重置执行应力测试、以确保稳定性。

此致、

Lucas

你好、卢卡斯、  

我们在非工作板中面临一个问题,其中操作系统正在进入内核恐慌与 SBL 修复.  （通过 FIX 我是指 SBL ,我们已经删除了由詹姆斯早期提供的行）.

我在这里附加了详细的操作系统启动日志、我们尝试使用我们使用的多个操作系统版本进行调试。

此外、我们还尝试查看 M4F 是否导致了问题、并删除了 SBL 中的 M4F 加载。 和内核恐慌问题涉及.  

e2e.ti.com/.../old_5F00_os.loge2e.ti.com/.../new_5F00_os.log

您好、

您是否说过以下修复：

此外、从 SW 团队收到此问题、请尝试：

请删除此行并重试：

https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/ddr/v0/soc l32x/am62x/ddr_soc.c#l322

包含的这段代码用于处理一些热复位问题、但不再需要

此致、

• 对工作板什么也没做（之前通过，现在仍然通过）
• 此修复对于某些电路板有效、但其他电路板仍然无法正常工作？

此致、

Lucas

您好、Lucas：  

   是的工作板仍然工作正常。 但在非工作板中、SBL 加载修复程序、并且在操作系统启动期间、它会进入内核错误、正如我在这些日志中提到的那样  

尊敬的 Lucas/ James：

   今天、我使用 ti-processor-sdk-linux-am62xx-evm-10.00.07.04 中提供的预构建映像进行了测试。 我同时使用了基于 initramfs 的操作系统 tisdk-tiny-initramfs-am62xx-evm.rootfs.cpio 和 tisdk-base-image-am62xx-lp-evm.rootfs.tar。 CPU 初始化后、两者都不会在超过特定点加载。

“我喜欢你射给我。  空指针取消引用问题。  我将附加使用这两种方法获取的日志。 在早期故障的电路板中、这种情况仍然存在。

在已经正常工作的电路板中不会出现这种情况。

[0.208925] SMP：总共激活了 4 个处理器。
[0.213736] CPU 特性：检测到：32 位 EL0 支持
[ 0.218999] CPU 功能：检测到：CRC32 指令
[ 0.224314] CPU：所有 CPU 均从 EL2 启动
[0.228509]备选办法：采用全系统备选办法
[0.234231]无法处理虚拟地址 ffff800083ec2d50 中的内核分页请求
[ 0.242322]存储器中止信息：
[0.245168] ESR = 0x0000000096006
[ 0.248993] EC = 0x25：DABT（电流 EL）、IL = 32 位
[ 0.254418] SET = 0、FnV = 0
[ 0.257532] EA = 0、S1PTW = 0
[0.260735] FSC = 0x06：2 级转换故障
[0.265715]数据中止信息：
[0.268651] ISV = 0、ISS = 0x00000006、ISS2 = 0x00000000
[ 0.274253] CM = 0、WNR = 0、TND = 0、TagAccess = 0
[ 0.279411] GCS = 0、覆盖层= 0、DirtyBit = 0、Xs = 0
[0.284836] swapper pgtable：4K 页、48 位 vas、pgdp=0000000082fba000
[0.291682][ffffff800083ec2d50] PgD=10000000f7fff003、p4d=10000000f7fff003、pud=10000000f7ff003、PMD=00000000000000000000
[0.302540]内部错误：oops：0000000096000006 [#1] Preempt SMP
[0.308944]模块链接于：
[0.312063] cpu：0 pid：1 comm: swapper/0 not tainted 6.6.32-ti-g6de6e418c80e-dirty #1.
[ 0.320157]硬件名称：Texas Instruments AM62x LP SK (DT)
[0.326026] pstate：800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSB BTYPE=-)
[0.333142] PC：fpsimd_thread_switch+0x34/0xd4
[0.337785] lr：__switch_to+0x20/0x12c
[0.341708] sp : ffff80008141bb40
[0.345089] x29：ffffff80008141bb40 x28：ffffff800081387000 x27：ffffff800081229000
[0.352386] x26：ffffff800080f47f50 x25：ffffffff0000004f8570 x24：ffffff800080bb434c
[ 0.359684] x23：ffffff800081229d50 x22：ffffff800080f47b40 x21：ffffff0000004f8000
[ 0.366981] x20：00000000005a0000 x19：ffffff0000005a0000 x18：0000000000000006
[0.374278] X17：3030383430383030 x16：303030307830 x15：ffffff80008141b7c0
[ 0.381574] x14：0000000000000000 X13：0000000000000035 x12：0000000000000001
[0.388871] x11：000000000000 x10：0000000000000001：0000000000000400
[0.396167] x8 : ffff000077b77280 x7 : ffffff000077b77200 x6 : ffffff0000004f808080
[ 0.403464] x5：ffffff0000004f8080 x4：000000000002 x3：0000000000000000
[0.410760] x2：ffff800080bc9e00 x1：ffff80008100f180 x0：ffffff8000811c2d50
[0.418058]呼叫跟踪：
[ 0.420552] fpsimd_thread_switch+0x34/0xd4
[ 0.424826]__SWITCH_TO+0x20/0x12c
[ 0.428389]__switch_to+0x20/0x12c
[0.431951]_schedule+0x264/0x9c4
[ 0.435513] PREEMPT_SCHEDULE+0x48/0x60
[ 0.439432] queue_stop_cpus_work.constprop.0+0xe8/0x10c
[ 0.444862] stop_machine_cpuslocked+0x13c/0x16c
[0.44959] STOP_MACHINE+0x34/0x54
[ 0.453140] apply_alternatives_all+0xe8/0x128
[0.457684] SMP_CPUS_DONE+0xa4/0xb4
[0.461335] SMP_init+0x68/0x88
[ 0.464545] kernel_init_freeable+0x100/0x288
[ 0.468996] kernel_init+0x24/0x1dc
[0.472558] ret_from_fork+0x10/0x20
[ 0.476213]代码：b94c4663 900082c1 d538d082 91002021 (900082c0)
[0.482441]--[结束跟踪 000000000000 ]-----
[0.487156]注意：swapper/0[1]退出并禁用 IRQ
[ 0.492583]注意：swapper/0[1]退出 preempit_count 2.

如果您需要更多详细信息、请告诉我  

e2e.ti.com/.../Booting-ti-sdk-base-image.txte2e.ti.com/.../Booting-ti-sdk-tiny-initramfs-image.txt

Shibi、我必须得到我们软件团队的帮助才能对此进行调查。   

我只是想根据 Lucas 所问的内容确认几件事情：

-根据您所描述的,它听起来像以前工作的电路板,即使有 SBL 修复,仍然工作,引导成功完成

-在不工作的板上,SBL 修复允许引导进一步进行,但随后会导致内核错误。  

-任何以前不工作的板在 SBL 修复后成功引导,还是所有这些板都导致内核错误?

当所有处理器都被激活时、内核错误的两个日志似乎都是正确的。  这可能表示存在某种电源问题、但仍为时过早。  我不确定这是否可行、但如果您可以尝试使用仅启用其中一个 CPU 内核的映像进行引导、这可能会为我们提供一条线索。

此致、

James

您好、James：

-根据您描述的内容、听起来前面的工作板似乎还在工作、即使使用了 SBL 修复、仍在工作、引导成功完成

       是的

-在非工作电路板上、SBL 修复允许引导进一步进行、但随后会导致内核错误。  [/报价]

       是的

-以前任何不工作的电路板在 SBL 修复后是否成功引导、或者是否所有这些电路板都导致内核错误？

      编号 没有任何不工作的电路板使用 SBL 修复进行引导。 它们在同一位置也表现出相同的行为。

我不怀疑电源是否正常、因为使用 SPL 引导加载程序 (tiboot3.bin、tispl.bin 和 u-boot.img) 时会成功加载相同的操作系统。

我不确定这是否可行、但如果您可以尝试使用仅启用其中一个 CPU 内核的映像进行引导、这可能有助于为我们提供线索。

我正在努力。 将更新。

[/quote]

你（嗨，Shibi）

我不怀疑电源、因为使用 SPL 引导加载程序 (tiboot3.bin、tispl.bin 和 u-boot.img) 时会成功加载相同的操作系统。

是的、说得好。  因此、SBL 可能设置一些初始条件、会加剧 SPL 不会设置的某些条件。  单核测试可能会向我们指出这一点、也可能会告诉我们去其他地方看看。

需要与软件团队进一步讨论

此致、

James

您好、James：

     我按照你的建议尝试了。 已尝试启用 1 个 CPU、2 个 CPU、3 个 CPU 和 4 个 CPU。 我观察到启用了 1 和 2 CPU 的操作系统能够正常启动、而 3 和 4 CPU 版本表现出相同的行为、并在出现内核错误时停止。 我附加了在启用了 2 个和 3 个 CPU 的情况下获取的日志

此致、

Shibi

e2e.ti.com/.../2-cpu-wokring.txte2e.ti.com/.../3-cpu-not-wokring.txt

尊敬的 Shibi：  

您能否提供使用 SPL 运行的 Linux 引导的完整引导日志？   

我还想通过读取 JTAG_USER_ID 寄存器来验证您的器件类型。  这可以从地址 0x43000018 的 uboot 读取。  请在工作板和非工作板上执行此操作。

在某些电路板上、似乎您有 2 核版本的器件。   

此致、

James

您好、James：  

      请找到使用 SPL 引导加载程序使用 4 个内核获取的完整日志。 所有电路板都使用 HS-SoC FS 型。 工作板和非工作板中的 0x43000018 寄存器值均与 0x3a60fcee 相同。

e2e.ti.com/.../SPL-boot-logs-with-4-core.txt

尊敬的 Shibi：

我在日志中注意到您使用的是不同版本的软件组件。  以下是我拍摄的日志差异的一些快照：

BL31

SYSFW

此示例显示您使用的是相同版本的 u-boot 2025.04、但看起来像是来自不同的 SDK (9.2.8 与 11.1.2)

为了缩小问题范围、最好同步这些不同组件的版本、以便更接近同类比较。  目前、我们认为问题可能是在 SDK11 中、某些软件组件的存储器映射发生了变化、SBL 可能无法正确理解这一点。   

此致、

James

您好、James：

     感谢您的评分 我们的团队已确定与 CPU 核心电力线相关的潜在硬件问题。 我们目前正在进行更多的调查。 请稍等、直至另行通知。

此致、

Shibi

哦、还可以。  谢谢您让我知道。   

James