AM6411: DDR ECC interrupt routing

Part Number: AM6411

Hi,

I've been trying to catch the DDR0_DDRSS_DRAM_ECC_CORR_ERR_LVL_0 interrupt in my linux kernel module, but it seems to be difficult. DDRSS0 routes it to ESM0, which apparently makes it available through TISCI. But in TISCI documentation I can only find the  DDR0_DDRSS_HS_PHY_GLOBAL_ERROR_0 (and others of the same block) that I could access through GIC500 or MAIN2MCU_LVL_INTRTR0 also. 

What is the supposed route to get this interrupt enabled?

Best Regards,

    Juha

  • Hello Juha,

    I am going to try to route your question to the correct team member to discuss. Feel free to ping the thread if you do not get another response within a few business days.

    In the meantime, this is some 

    Regards,

    Nick

  • In the meantime, this is some output from one of my AI agents. it looks reasonable, but I have not verified all of the claims. I suggest cross-referencing any presented information before using anything posted below:

    "

    Your observation is correct — this is a hardware routing limitation, not a documentation gap.

    The route (per the AM64x TRM):

    Signal Destination Line
    DDR16SS0_DDRSS_DRAM_ECC_CORR_ERR_LVL_0 ESM0 ESM0_LVL_IN_6
    DDR16SS0_DDRSS_DRAM_ECC_UNCORR_ERR_LVL_0 ESM0 ESM0_LVL_IN_69
    DDR16SS0_DDRSS_CONTROLLER_0 COMPUTE_CLUSTER0 (GIC) GICSS0_SPI_IN_151
    DDR16SS0_DDRSS_V2A_OTHER_ERR_LVL_0 ESM0 ESM0_LVL_IN_110

    1

    Why you can't find it in the TISCI interrupt_cfg doc: the ECC correctable/uncorrectable error signals are hardwired directly into ESM0 only. They are not fanned out to GIC500 or MAIN2MCU_LVL_INTRTR0, so they will never show up as a TISCI-routable interrupt for those aggregators — that's expected, not a missing entry. Only the "HS PHY Global Error" and "Controller" interrupts from the same DDRSS0 block have that broader fanout, which is why those are the ones you found in the interrupt_cfg page.

    Implication for your kernel module: you cannot get DDR0_DDRSS_DRAM_ECC_CORR_ERR_LVL_0 delivered to Linux as a standalone GIC interrupt via TISCI/ti,sci-intr/ti,sci-inta the way you would for a normal peripheral IRQ. It is consumed by ESM0 as an error-signaling event, not as a general-purpose routable interrupt endpoint.

    Practical way to catch it from Linux:

    • ESM0 event routing/enabling is done through the bitmap-style config (enableBitmap, priorityBitmap, errorpinBitmap) described in the SDL SDL_ESM_config structure, mapped against the ESM interrupt map table in the TRM. Event bit position = event number mod 32; group = event number / 32. For ESM0_LVL_IN_6, that's bit 6 of group 0 2.
    • ESM0 itself then raises its own aggregated interrupt line (e.g., high-priority/low-priority ESM output) to a CPU — this ESM output interrupt is what actually shows up in the GIC/TISCI interrupt tables, not the individual DRAM ECC event itself.
    • On Linux, this typically means you need the TI ESM driver (drivers/soc/ti/k3_r5_remoteproc adjacent ESM support, or CONFIG_TI_ESM) to be enabled/probed for ESM0, and your kernel module should hook into that ESM driver's notification mechanism (or extend it) rather than trying to request a GIC IRQ directly for the DDRSS ECC event.
    • There is no TISCI SoC doc mechanism to reroute this event out of ESM0 to GIC500 directly — ESM0 is the fixed, final destination for that specific ECC signal in hardware.

    No further public TI documentation was found describing a Linux-specific ESM-to-userspace/kernel-module notification API beyond the SDL bitmap configuration model — if your kernel module needs the ECC event, it will need to interface with (or extend) whatever ESM handling exists in your kernel/SDK, rather than expecting a standalone IRQ number for DDR0_DDRSS_DRAM_ECC_CORR_ERR_LVL_0.

    "

    The SDL configuration mentioned came from this FAQ which was for MCU+ SDK, not linux SDK:
    [FAQ] AM64X/AM62X/AM62AX : Configuring the ESM module from SDL and setting the ESM Bit Fields to enable the ESM Error events

  • Thanks for this, it pretty much confirms my suspicion that I need to configure and catch the esm hi/lo interrupts. Which I guess is working, but how would I proceed to inject a 1-bit error in the memory in the runtime? TRM discussed this being a feature of the ECC Aggregerators, but I couldn't find information on the DDRSS registers for similar functionality. Since I'm additionally implementing this with j7200, I found the app note "DDR Inline ECC Error Injection and Validation Guide for JacintoTm 7 and SitaraTm Processors" (sdaa513.pdf), but it only discusses the process, not so much technical details. I tried the suggested way of reserving a memory block in kernel dts, disabling (setting the ecc region start greater than region end address) ecc and flipping a bit in the reserved block, but re-enabling the ecc just crashes the kernel/board (it seems to vary a bit). 

    For a start I'd be happy with just information how to trigger ESM events manually.

  • Hi Juha,

    Please see if the implementation of U-Boot DDR ECC command helps.

    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/cmd/ti/ddr4.c?h=ti-u-boot-2026.01