Re: EDAC support for Arrow Lake-HX (8086:7d1c) - working out-of-tree driver, test hardware available

Hello Zura,

On 7/10/2026 2:58 PM, Emba Consulting wrote:
> Hi,
> 
> I have Arrow Lake-HX hardware running sideband (80-bit) DDR5 ECC SODIMMs
> and wanted EDAC error reporting for it. As of current mainline no driver
> matches this die: igen6_edac covers the in-band-ECC Arrow Lake-U/H compute
> dies (0x7d06/0x7d20/0x7d30), and ie31200_edac (which gained Raptor Lake-S,
> Raptor Lake-HX and Bartlett Lake-S support recently) has no 7dxx IDs.
> 
> I wrote an out-of-tree driver derived from ie31200_edac and it works on my
> machine - both IMCs register, DIMM topology decodes exactly, counters are
> live, clean load/unload:
> 
>   https://github.com/zs311521/edac-arl-hx
> 
> Hardware:
> - Intel Core Ultra 9 285HX (Arrow Lake-HX), stepping 2, microcode 0x11b,
>   host bridge 00:00.0 = 8086:7d1c rev 01 (Minisforum MS-02)
> - 2x SK hynix HMCG88AGBAA095N 32GB DDR5-5600 ECC SODIMM (2Rx8, one per IMC)
> - BIOS reports Single-bit ECC active; MCHBAR = 0xfedc0000
>

I have an Intel Core Ultra 7 270K Plus (Arrow Lake-S Refresh), and it
appears to be 8086:7d1a. I'll test your driver, thanks!

> Findings, in case they are useful:
> - The register layout matches rpl_s_cfg for topology and error-log offsets.
>   I validated from userspace before loading anything: MAD_DIMM at
>   MCHBAR+0xd80c/+0xd810 decodes the physical population exactly (16 GiB,
>   2 ranks, x8 per subchannel), ECCERRLOG at +0xe048/+0xe848, two IMC
>   windows at BIT(16) stride.
> - I deliberately did NOT reuse the MSR 0x791 error-log clear: the public
>   EDC documentation for this family (doc 835538) describes clearing via
>   PCI ERRSTS instead, and I could not verify the MSR's semantics on this
>   die, so my module defaults to a no-write polling mode with
>   report-on-change latching.
> - Channel count is derived from MAD_DIMM population rather than CAPID0.
> - My BIOS exposes no ACPI EINJ table, so I have not been able to exercise
>   a real corrected error end to end.
> 
> Questions, so this can become a proper mainline patch (which I am happy to
> write and submit as a dedicated cfg in ie31200_edac if you can confirm):
> 
> 1. Is MSR 0x791 valid with the same semantics on ARL-HX, or should the
>    error-log clear go through ERRSTS (or something else) on this die?
> 2. Is corrected-error CMCI delivery confirmed for ARL-HX out-of-band ECC,
>    i.e. is .cmci = true correct here?
> 3. Should ARL-HX reuse rpl_s_cfg or get a dedicated cfg? The rank/width
>    field widths in the ARL documentation look narrower than rpl_s_cfg's
>    masks.
> 
> I can test patches on this machine and provide Tested-by.
> 
> Thanks,
> Zura

-- 
Best, 
Chaoyi