[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Tom Rini <trini@konsulko.com>]

On Fri, Mar 10, 2017 at 05:55:37PM +0200, Siarhei Siamashka wrote:
> On Wed, 8 Mar 2017 09:30:07 -0500
> Tom Rini <trini@konsulko.com> wrote:
> 
> > On Mon, Mar 06, 2017 at 03:16:53AM +0200, Siarhei Siamashka wrote:
> > 
> > > The workaround for ARM errata 725233 had been lost since
> > > commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
> > > maintenance framework). Bring it back in order to avoid
> > > very difficult to reproduce, but actually encountered in
> > > the wild CPU deadlocks when running software rendered
> > > X11 desktop on OMAP3530 hardware.
> > > 
> > > This patch adds the new errata define to the whitelist instead
> > > of introducing a new Kconfig option. It's probably best to
> > > convert all ARM errata to Kconfig in one go via a separate
> > > patch.
> > > 
> > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>  
> > 
> > In concept:
> > Reviewed-by: Tom Rini <trini@konsulko.com>
> 
> Thanks!
>  
> > Do you want to v2 on top of my patch that migrates the current ARM
> > errata or would you rather I v2 it and apply?  Thanks again!
>  
> Sure, either way is fine for me.

OK.  I'm building the conversion now.

> There is just one thing that is not very good yet. Setting the
> L2 Auxiliary Control Register is currently a no-op in my patch
> for the HS variants of OMAP3430/3530 because they are using a
> different secure monitor API. And I don't know anything
> about it and don't even have such hardware to run any tests.
> 
> And there is not much that can be done about it there. We have
> no serial console yet to print any diagnostic warnings.
> 
> So I wonder if it makes sense to add one more errata related
> patch, responsible for verifying correctness of the applied
> errata workarounds at a much later stage. Basically, the difference
> is the following. When applying errata workarounds:
>   * Writing to coprocessor registers is restricted and may
>     require the use of SoC-specific secure monitor API.
>   * Errata workarounds need to be applied as early as possible
>     and we don't have the serial console for any debugging
>     or diagnostic messages yet.
> And when validating errata workarounds:
>   * Reading coprocessor registers is not a problem and can be
>     done via a simple MRC instruction.
>   * The validation can be done at any time, even postponed
>     until just before loading the OS kernel. We can print
>     warnings if something is not right or even abort booting
>     (after printing a comprehensive error message).
> 
> So if I implement such additional errata validation patch, then
> anyone with a HS OMAP3430 device can notice that there is a
> problem and implement the missing L2 Auxiliary Control Register
> setup code. What do you think about this?

Adding an optional verification stage (or command) could be interesting.
I don't see a problem in concept with adding something, again so long as
it's optional.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170310/89a09c13/attachment.sig>