On 11/06/2016 06:42 PM, Shengzhou Liu wrote: > >> -----Original Message----- >> From: york sun >> Sent: Friday, November 04, 2016 11:20 PM >> To: Shengzhou Liu <shengzhou....@nxp.com>; u-boot@lists.denx.de >> Subject: Re: [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related >> erratum >> >> On 11/04/2016 04:18 AM, Shengzhou Liu wrote: >>> - add additional function erratum_a009942_check_cpo to check if the >>> board needs tuning CPO calibration for optimal setting. >>> - move ERRATUM_A009942(with revision to check cpo_sample option) >> from >>> fsl_ddr_gen4.c to ctrl_regs.c for reuse on all DDR4/DDR3 parts. >>> - move ERRATUM_A008378 from fsl_ddr_gen4.c to ctrl_regs.c >>> - remove obsolete ERRATUM_A004934 which is replaced with >> ERRATUM_A009942. >> >> Shengzhou, >> >> There is an issue for moving the erratum 9942 workaround to ctrl_regs.c. >> This workaround requires setting debug register in a read-modify-write >> fashion. You won't be able to read the debug register in ctrl_regs.c file. >> >> York > > York, > > This change(moving to ctrl_regs.c) has the same effect as > read-modify-write(done in fsl_ddr_gen4.c) before MEM_EN is enabled for DDRC. > As I commented in code with "the POR value of debug_29 register is zero" for > A009942 workaround when moving it to ctrl_regs.c, > Actually only A008378 changes debug_29[8:11] bits to 9 from original POR > value 0 before the implementing of A009942, and A009942 overrides > debug_29[8:11] set by A008378. > So we can set debug_29 in ctrl_regs.c, it doesn't break anything.
Shengzhou, The presumption of POR value is not safe. It is safe for this case for now. You may have other erratum workaround popping up later using the same register, or other registers. PBI can also change registers. This sets an example to preset those registers out the scope of hardware interaction, regardless which controller is in use, or its state. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
