[参考译文] TDA4VM：J721E 中的内联 ECC 错误处理

您好、

我们的专家正在参加研讨会、请期待收到延迟的答复。

此致、
Sudheer

您好、

感谢您发送详细的电子邮件。   有一个概述链接可用、您可能已经看到：

8.13.为 DDR 启用 TI 的内联 ECC—Processor SDK RTOS J721E

在具体细节方面、将会让更熟悉 uboot 引导流程的人循环访问。   如果您发布 dtsi 修改、它可能会并行提供帮助。

此致、

KB

尊敬的、KB：  

感谢您的反馈。  

请查看下面的红色修改：  

我想检查此"延迟初始写入"解决方案是否在 A72 u-boot 中有效。

如果 ECC 错误处理流程可用并在 u-boot 中正常工作、则 我可以将其应用于 Linux。

提前感谢您的支持!

您好、

在 u-boot k3-ddrss 驱动程序中、您是否可以尝试删除 k3_ddrss_lpddr4_ecc_init 中的 ECC_CK 启用 ？

然后、在初始写入后将其重新添加到 u-boot 提示符中。

此致、
Jared

您好、Jared、  

感谢您的快速答复。  

但是 建议在使用 DDR 之前设置 ECC_CK 。 (以及 RMW_EN)

我不确定是否可以将 ECC_CK 启用从 R5 u-boot 阶段推迟到引导后阶段(例如、在 u-boot 或 Linux 启动之后)

不管怎样、我明天去实验室试一下。

谢谢。

您好、

您能尝试设置寄存器吗  EMIF_ew_ctlcfg_DDRSS_CTL_206 。 ECC_ENABLE  字段更改为1、以便启用 ECC、但不会检测或纠正错误？

此致、
Jared

您好、Jared、  

请检查下面的更新

测试#01：将 ECC_CK 启用推迟到 A72 u-boot 提示符

似乎可以在运行时启用 ECC_CK、但 ECC 错误中断未正常触发。  

测试#02：访问 DDRSS_CTL_206寄存器  

=> MD.l 0x02990338 0x1
02990338: 02000fff .
=> mw.l 0x02990338 0x02010fff    //将 ECC_ENABLE 字段位[17-16]设置为1
=> MD.l 0x02990338 0x1
02990338：02010fff

注意：MSM2DDR 和 DDR 控制器均提供 ECC 功能、但只能启用一项 ECC 功能。

指定  TI-PROCESSOR-SDK-LINUX-ADAS-j721e-EVM-10_01_00_04 、 似乎只有 MSM2DDR ECC 驱动程序在 r5-uboot 中可用。

您建议使用 DDR 控制器 ECC 功能吗？  是否有可用的 u-boot 修补程序？  

谢谢。

尊敬的 Leon：

Unknown 说：

您建议使用 DDR 控制器 ECC 功能吗？

您应该使用 MSMC2DDR 控制器、因为它更优。

Unknown 说：

是否有任何 u-boot 补丁可用？  [/报价]

否、没有可用于此目的的 u-boot 补丁、因为这以前没有做过。

我将单独进行一些测试、但在此期间您能回答我的问题吗？ 这最终将如何改进您的系统？ 您仍然必须先设置对 DDR 的初始写入、才能在需要 ECC 的 Linux 中正确执行任何操作、并且速度会变慢、因为它不使用 BIST。  

此外、在 Linux 同时使用 DDR 时、您如何配置内存？

此致、
Jared

您好、Jared、  

让我澄清一下。  

启用内联 ECC 功能后、在 R5 u-boot 阶段、对受 ECC 保护的 DRAM 进行额外的初始写入(即使使用 BIST)也将增加引导延迟。

对引导延迟敏感的系统(例如汽车系统)不友好

我的想法是将初始写入从 R5 u-boot 阶段推迟到 Linux-POST 阶段。

这意味着 Linux 可以在短时间内启动(例如、屏幕亮起、摄像头打开)、 然后后台软件运行初始写入、但现在它不会影响用户体验。  

我已经有了软件解决方案,可以在特定 DRAM 区域上进行后期写入,不会影响 Linux 内核。

最后一个缺失部分是 ECC 保护区初始写入的 ECC 错误句柄(由 RMW 策略导致)  

我可以收到您的电子邮件,或在私聊中讨论吗? 我可以向您分享更多详细信息。

提前感谢您的支持:-)

您好、

您当前正在测试不属于 DRAM 范围的内存。 如果运行 bdinfo、则可以查看 DRAM 存储器在寻址中的位置。

=> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000080000000
-> size     = 0x0000000080000000
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000880000000
-> size     = 0x0000000080000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x00000000ffebe000
reloc off   = 0x000000007f6be000
Build       = 64-bit
current eth = ethernet@46000000port@1
ethaddr     = 24:76:25:a5:73:11
IP addr     = <NULL>
fdt_blob    = 0x00000000fde79740
new_fdt     = 0x00000000fde79740
fdt_size    = 0x0000000000024660
multi_dtb_fit= 0x0000000000000000
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]	[0x80000000-0xffffffff], 0x80000000 bytes flags: 0
 memory[1]	[0x880000000-0x8ffffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x5 / max = 0x10
 reserved[0]	[0x9e800000-0xb7ffffff], 0x19800000 bytes flags: 4
 reserved[1]	[0xb8000000-0xd7ffffff], 0x20000000 bytes flags: 0
 reserved[2]	[0xd8000000-0xe5ffffff], 0x0e000000 bytes flags: 4
 reserved[3]	[0xfce75000-0xffffffff], 0x0318b000 bytes flags: 0
 reserved[4]	[0x880000000-0x8a6ffffff], 0x27000000 bytes flags: 4
devicetree  = separate
serial addr = 0x0000000002800000
 width      = 0x0000000000000000
 shift      = 0x0000000000000002
 offset     = 0x0000000000000000
 clock      = 0x0000000002dc6c00
arch_number = 0x0000000000000000
TLB addr    = 0x00000000fffe0000
irq_sp      = 0x00000000fde79730
sp start    = 0x00000000fde79730
Early malloc usage: 3648 / 8000

DRAM 落在以下范围内：0x8000000到0x900000000。 您是否可以将存储器设置在此范围内来运行测试？

另请注意、看看 BIST 将设置的存储器、范围为0xe0000000 (8/9 * 0x1000000000)。

您遇到的错误可能是由于您尝试访问无法访问的系统寄存器。

此致、
Jared

您好、Jared、  

感谢您的反馈

我再次检查我的上一篇文章,发现我的第一篇文章的描述有拼写错误,我添加了一个额外的零起始地址...

我已经纠正了它在我的第一篇文章, ECC 保护区应该是 0xC000-000 ~ 0xD000-1000, 对不起的误解...

但我的测试命令序列是正确的、您可以在我的第一个帖子中检查日志。

让我们重点看一下我的第一个测试后序列、 测试区域属于组0范围：

感谢您的提醒。

我不熟悉 BIST、为避免使用它、我 用 CPU 作为临时解决方案、编写一个函数来初始写入 ECC 保护区的一部分(0xC000-0000 ~ 0xD000-0000)。  左0xD000-0000 ~ 0xD000-1000区域未写入。  

毕竟、我的最终用途根本不是在 u-boot 中运行 ECC 受保护区域的初始写入。

static void k3_ddrss_preload_ecc_mem_region(u64 *addr, u64 size, u64 pattern)
{
    u64 i = 0; 
    static u64 count = 0; 
    for (i = 0; i < (size / 8); i++) 
    {    
        if( count % 0x01000000 == 0)
            printf(".");

        addr[i] = pattern;
        count++;
    }    
}

static void k3_ddrss_lpddr4_ecc_init(struct k3_ddrss_desc *ddrss)
{
    ... skip ...
    // init ecc area on low mem
    printf("---> leonwang add %s %d init write to cpu addr: 0xC000_0000 + 0x1000_0000\n", __FILE__, __LINE__);
    k3_ddrss_preload_ecc_mem_region( (u64 *)0xC0000000, 0x10000000, 0x12345678deadbeef);
    ... skip ...
}

现在技术障碍我是,如何处理 ECC 错误在初始写在 u-boot 提示符? (以及在 Linux-POST 阶段)

u-boot 中没有 ECC 错误处理程序、一旦发生 ECC 错误、u-boot 将复位。 (我想处理 ECC 错误并让系统继续运行)

我面前似乎有两个选项：

1. 解决方法：忽略 ECC 错误、只需在初始写入期间暂时禁用 ECC 错误中断；
   1. 但在我的测试中、会发生意外的"同步中止"。 我仍然不知道如何避免或处理它
2. 服务 ECC 中断：我研究了 J721E TDA4VM TRM、下面是几个与 ECC 相关的寄存器、但没有有关处理流的详细信息、例如：
   1. DDRSS_ECC_1B_ERR_ADR_LOG_REG、 我修补  DO_SYNC ()并在发生错误时转储它、那么 如何从寄存器内容解码错误地址？
   2. DDRSS_V2A_INT_STAT_REG、TRM 显示"写入1以清除状态 之后 中断已被处理"、那么如何处理 ECC 中断？

你有什么建议吗?

是否有任何 ECC 错误处理文档或示例代码可供参考？

再次感谢您的支持:-)

此致

Leon

尊敬的 Leon：

有有关 ECC 处理的 RTOS SDK 文档： https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/10_01_00_04/exports/docs/sdl/sdl_docs/userguide/j721e/modules/ecc.html 

对于您的 Linux 映像、我启用 ECC 后也会看到同步中止。 只要我推迟 错误计数寄存器清除、ECC1BERR_EN、ECC2BERR_EN、ECCM1BERR_EN 和 ECC_CK、我就没有看到任何问题。

在写入 Linux 中的初始存储器之前、是否可以尝试暂停设置以下寄存器？

另一种选择是尝试仅为 ECC 设置特定范围(并写入这部分)、而不是尝试整个 RAM。

此致、
Jared

您好、Jared、  

非常感谢您的建议！

它的工作是推迟 ECC_CK 启用,直到在 Linux 提示符下完成对 ECC 保护区域的初始写入 :-)

这应该是一个很好的权变措施解决方案、以避免在 Linux 内核中使用额外的 ECC 句柄。

但一个问题是推迟 ECC_CK 不是典型用法、它违反了数据表中的建议。  

您是否知道以前有人(客户)这样做？

或者您预计会有任何潜在风险吗?

提前感谢您的支持。

此致、  
Leon

尊敬的 Leon：

我不知道有人在做这件事。 我也不知道这种变化是否会增加风险。

我会询问我们的一些其他专家是否有任何意见/知识、并返回给您。

此致、
Jared