工具与软件:
尊敬的 TI 专家:
HW ENV:TDA4Ven EVM 板
SW ENV:SDK10.0
引导模式:使用 SD 卡进行 SBL 引导
将 DDR 密度从8g 修改为4g 并使用 memtester 命令测试 DDR 后、 测试结果不符合预期。
使用 memtester 70M 可以成功测试。
使用 mentester 命令超过80M 时、控制台被阻止、无法通过使用 Ctrl+c 退出、只能通过关闭和打开来恢复正常运行。

此致。
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.
工具与软件:
尊敬的 TI 专家:
HW ENV:TDA4Ven EVM 板
SW ENV:SDK10.0
引导模式:使用 SD 卡进行 SBL 引导
将 DDR 密度从8g 修改为4g 并使用 memtester 命令测试 DDR 后、 测试结果不符合预期。
使用 memtester 70M 可以成功测试。
使用 mentester 命令超过80M 时、控制台被阻止、无法通过使用 Ctrl+c 退出、只能通过关闭和打开来恢复正常运行。

此致。
尊敬的 Xie:
正确的理解是 、您只看到了 SBL 而没有 SPL 问题。 如果是、这 似乎确认了该问题不应 与 DDR 寄存器设置相关。
让我看看我们软件团队的人员是否可以提供进一步帮助。
SBL 引导是否可以适应 DDR 修改而不仅仅是替换 board_ddrReginit.h?
对于从硬件角度配置 DDR 子系统、这应该就足够了。 即、只要软件/CPU 尝试在有效范围内访问存储器、 它就应该就足够正常工作。
但从系统软件的角度来看、可能需要更新其他位置的总存储器大小、以防止软件尝试访问没有物理存储器的存储器位置。 例如、如果用户正在编译代码、并将代码链接到特定的内存区域、编译脚本可能会定义内存地址范围。 那么代码可能会链接到不存在物理存储器的地址。 不过这只是一个示例-最终、软件团队需要确认对 DDR 存储器总大小做出了哪些假设以及如何确定这些假设。
u-boot 代码中过去会出现这种类型的问题、这会将总内存大小传递给 Linux 内核。 DDR 工具的输出由 DDR 驱动程序使用、该驱动程序由 R5内核(tiboot3.bin)初始化。 但是、总存储器大小是从 A72 二进制文件(tispl.bin / u-boot.img)传递的、 其中不存在 DDR 驱动程序。 因此、需要手动更新 A72 u-boot 映像中的总存储器大小、以便 Linux 内核知道正确的可用存储器容量 (请参阅以下应用手册中的第3.1.2节: https://www.ti.com/lit/pdf/spracu8)。 我无法跟上较新的 SDK 版本、因此我不知道有哪些变化或您的特定 SDK 有哪些独特之处。
此致、
Kevin
尊敬的 Kevin:
谢谢。 我将通过 https://www.ti.com/lit/pdf/spracu8进行修改 、并为您提供反馈。
但我仍然感到困惑的是、从 SPL 到 SBL 的引导模式、Uboot、kernel 和 FS 都是相同的文件。 为什么在 SBL 引导?时会出现 memtester 故障的问题
此致。
尊敬的 Xie JC:
[报价 userid="512804" url="~/support/processors-group/processors/f/processors-forum/1438413/tda4ven-q1-memtester-issue-in-sbl-boot-mode/5528086 #5528086"]但我仍然感到困惑的是、从 SPL 到 SBL 的引导模式、Uboot、kernel 和 FS 都是相同的文件。 为什么在 SBL 引导?时会出现 memtester 故障的问题
[报价]您能告诉我您使用的是哪种引导流程吗?
此致、
Karthik