double-bit ECC failures that occur during load from ICCM do not set cptra_hw_error_fatal::iccm_ecc_unc

[korran]

To reproduce:

Corrupt a word in ICCM, and try to load it with the lw instruction.

The only symptoms that occur when this happens are an NMI with generic MCAUSE 0xf000_0001 (NMI_CAUSE_DBUS_NON_BLOCKING_LOAD_ERROR):

mcause: 0xf0000001,
mscause: 0x0,
mstatus: 0x1800,
mtval: 0x0,
cptra_hw_error_fatal: 0x0
cptra_hw_error_enc: 0x0
cptra_hw_error_non_fatal: 0x0
error_internal_intr_r: 0x0

If this happens in the field, it will difficult to root-cause it, as there doesn't seem to be any indication to the uC an ECC error occurred.

[Nitsirks]

Digging into VeeR logic here. Looks like the iccm ecc double error fires only on IFU requests to ICCM. When LSU does a DMA to the ICCM it just flags it as a bus error (same with DMA to DCCM as far as I can tell).

Found this in the PRM:

[bharatpillilli]

That makes sense because the data retrieval is not an IFU operation. This would be similar to operation on the bus where there is a parity error (I understand that our bus doesnt support parity errors :-)).

[korran]

@bharatpillilli I'm fine with the fault being a generic fault, but we need some mechanism to tell that ECC was the cause of the fault. When this happens, I would like to see the hardware set the iccm_ecc_unc bit in the soc_ifc.cptra_hw_error_fatal register.

[calebofearth]

This error could be communicated to the SoC by writing to the cptra_fw_error_fatal register, which will also trigger the cptra_error_fatal output pin. Firmware should probably be doing this for any NMI it encounters already.

I understand that an NMI may be unrecoverable and firmware might be unable to set the register - but this is the best option with current hardware.

[korran]

The firmware is already setting the cptra_fw_error_fatal register in response to the NMI, but it looks like a fault that could be caused by buggy firmware. AFAICT only internal CPU signals know that this was actually caused by an ECC error.