| Message ID | 20190322143036.28151-2-marex@denx.de |
|---|---|
| State | Accepted, archived |
| Delegated to: | Simon Goldschmidt |
| Headers | show |
| Series | [U-Boot,1/2] ARM: socfpga: Pull PL310 clearing into common code | expand |
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 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: Dalon Westergreen <dwesterg@gmail.com> Cc: Dinh Nguyen <dinguyen@kernel.org> --- arch/arm/mach-socfpga/spl_a10.c | 1 + 1 file changed, 1 insertion(+)