On 05/23/2016 10:15 PM, Shengzhou Liu wrote: > >> -----Original Message----- >> From: York Sun [mailto:york....@nxp.com] >> Sent: Monday, May 23, 2016 11:33 PM >> To: Shengzhou Liu <shengzhou....@nxp.com>; u-boot@lists.denx.de >> Subject: Re: [PATCH] driver/ddr/fsl: Force enabling parity for A-009803 >> Shengzhou, >> >> My point is you should force ap=1. Do you mean if ERRATUM_A009803 is >> enabled, users are forced to use address parity? That doesn't sound right. >> We have been running UDIMM without address parity for a long time. >> >> York >> > York, > My understanding is that ERRATUM_A009803 may still happen whatever ap_en is > enabled or disabled. > To apply the workaround of A009803, it requires ap_en is enabled. Is your > understanding that if we > disable ap_en, ERRATUM_A009803 will never happen? The CE document doesn't > explain clearly this. > In last mail, did you mean we should force ap_en = 0 in case of A-009803? >
Sorry I had a typo. I meant you should NOT force ap=1. Let me explain. The erratum tells you _if_ address parity is used, for either UDIMM or RDIMM, you need to implement the workaround, as step 1, 2, 3, ... We understand users don't have a choice for RDIMM, the address parity is always enabled. But for UDIMM, users can choose not to enable it. Your _this_ patch forces the address parity to be true, regardless of user's choice. I think this is wrong. The erratum always applies to affected SoCs, but the address parity is not always enabled. That's what I meant for "condition". York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
