[U-Boot,2/2] ARM: socfpga: Clear PL310 early in SPL

On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
will result in stale data in PL310 L2 cache controller. Even if the L2
cache controller is disabled via the CTRL register CTRL_EN bit, those
data can interfere with operation of devices using DMA, like e.g. the
DWMMC controller. This can in turn cause e.g. SPL to fail reading data
from SD/MMC.

The obvious solution here would be to fully reset the L2 cache controller
via the reset manager MPUMODRST L2 bit, however this causes bus hang even
if executed entirely from L1 I-cache to avoid generating any bus traffic
through the L2 cache controller.

This patch thus configures and enables the L2 cache controller very early
in the SPL boot process, clears the L2 cache and disables the L2 cache
controller again.

The reason for doing it in SPL is because we need to avoid accessing any
of the potentially stale data in the L2 cache, and we are certain any of
the stale data will be below the OCRAM address range. To further reduce
bus traffic during the L2 cache invalidation, we enable L1 I-cache and
run the invalidation code entirely out of the L1 I-cache.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
---
 arch/arm/mach-socfpga/spl_a10.c | 1 +
 1 file changed, 1 insertion(+)

On 07.05.19 21:20, Marek Vasut wrote:
> On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
> will result in stale data in PL310 L2 cache controller. Even if the L2
> cache controller is disabled via the CTRL register CTRL_EN bit, those
> data can interfere with operation of devices using DMA, like e.g. the
> DWMMC controller. This can in turn cause e.g. SPL to fail reading data
> from SD/MMC.

I bet this is copy & paste from the gen5 patch? It should probably say 
"On SoCFPGA A10 systems"?

Other than that:
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

> 
> The obvious solution here would be to fully reset the L2 cache controller
> via the reset manager MPUMODRST L2 bit, however this causes bus hang even
> if executed entirely from L1 I-cache to avoid generating any bus traffic
> through the L2 cache controller.
> 
> This patch thus configures and enables the L2 cache controller very early
> in the SPL boot process, clears the L2 cache and disables the L2 cache
> controller again.
> 
> The reason for doing it in SPL is because we need to avoid accessing any
> of the potentially stale data in the L2 cache, and we are certain any of
> the stale data will be below the OCRAM address range. To further reduce
> bus traffic during the L2 cache invalidation, we enable L1 I-cache and
> run the invalidation code entirely out of the L1 I-cache.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Chin Liang See <chin.liang.see@intel.com>
> Cc: Dalon Westergreen <dwesterg@gmail.com>
> Cc: Dinh Nguyen <dinguyen@kernel.org>
> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
> ---
>   arch/arm/mach-socfpga/spl_a10.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
> index c8e73d47c0..8eb856f3d8 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -81,6 +81,7 @@ void board_init_f(ulong dummy)
>   
>   	socfpga_init_security_policies();
>   	socfpga_sdram_remap_zero();
> +	socfpga_pl310_clear();
>   
>   	/* Assert reset to all except L4WD0 and L4TIMER0 */
>   	socfpga_per_reset_all();
>

On 5/7/19 9:42 PM, Simon Goldschmidt wrote:
> 
> 
> On 07.05.19 21:20, Marek Vasut wrote:
>> On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
>> will result in stale data in PL310 L2 cache controller. Even if the L2
>> cache controller is disabled via the CTRL register CTRL_EN bit, those
>> data can interfere with operation of devices using DMA, like e.g. the
>> DWMMC controller. This can in turn cause e.g. SPL to fail reading data
>> from SD/MMC.
> 
> I bet this is copy & paste from the gen5 patch? It should probably say
> "On SoCFPGA A10 systems"?

Nice find, fixed.

> Other than that:
> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Thanks