[U-Boot] [PATCH] ARM: socfpga: Clear PL310 early in SPL

[Marek Vasut]

On 2/19/19 2:58 PM, Simon Goldschmidt wrote:
> 
> 
> Am Di., 19. Feb. 2019, 14:45 hat Marek Vasut <marex at denx.de
> <mailto:marex at denx.de>> geschrieben:
> 
>     On 2/19/19 2:28 PM, Simon Goldschmidt wrote:
>     > On Tue, Feb 19, 2019 at 1:53 PM Marek Vasut <marex at denx.de
>     <mailto:marex at denx.de>> 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.
>     >>
>     >> 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 at denx.de <mailto:marex at denx.de>>
>     >> Cc: Dalon Westergreen <dwesterg at gmail.com
>     <mailto:dwesterg at gmail.com>>
>     >> Cc: Dinh Nguyen <dinguyen at kernel.org <mailto:dinguyen at kernel.org>>
>     >
>     > We've tested this and it seems to fix the issue, so:
>     >
>     > Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com
>     <mailto:simon.k.r.goldschmidt at gmail.com>>
>     >
>     > However, I don't really get why clearing the L2 cache later in U-Boot
>     > isn't good enough.
> 
>     Because when U-Boot is running, it is already running from RAM, which is
>     on different PL310 master than OCRAM, and you're likely to hit the
>     corrupted cache lines on the DRAM master which is primed by prior Linux
>     operation. Such cacheline can be hit between the code enabling the PL310
>     and the code invalidating it, which is a C code, using stack and calling
>     functions, thus accessing memory which would likely reside in different
>     PL310 cachelines. If one of those cachelines contains invalid/corrupted
>     data, they can be provided to the CPU before the cacheline is
>     invalidated.
> 
>     To further reduce the likelihood of hitting any such cache line, the
>     code which enables the PL310 and invalidates it runs from primed L1
>     icache lines, thus generating no bus traffic at all.
> 
> 
> Ah, right. I somehow didn't realize that invalidating is done after
> enabling:-)

Right. If it could be done before (like e.g. by whacking the L2CC
reset), that'd be fantastic.

>     > Also, wouldn't this affect other platforms as well?
> 
>     I had the same concern, however I suspect it might have to do with the
>     reset implementation on SoCFPGA, which doesn't clear the L2CC, while
>     reset implementations on other SoCs likely do clear the L2CC. I am
>     however inquiring with Altera/Intel about this.
> 
> 
> Ok, thanks for the explanation!

Sure

-- 
Best regards,
Marek Vasut