Multi-platform, and secure-only ARM errata workarounds

From: pdeschrijver@nvidia.com (Peter De Schrijver)
To: linux-arm-kernel@lists.infradead.org
Subject: Multi-platform, and secure-only ARM errata workarounds
Date: Tue, 5 Mar 2013 09:40:47 +0200	[thread overview]
Message-ID: <20130305074047.GH27241@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <5134D50B.8060001@wwwdotorg.org>

On Mon, Mar 04, 2013 at 06:08:27PM +0100, Stephen Warren wrote:
> On 03/04/2013 02:16 AM, Peter De Schrijver wrote:
> > On Mon, Mar 04, 2013 at 07:34:36AM +0100, Peter De Schrijver wrote:
> >> On Fri, Mar 01, 2013 at 06:37:27PM +0100, Stephen Warren wrote:
> >>

...

> > 1) Handle CPU0 errata WARs in the bootloader
> 
> OK - there's not much choice here, and I've posted a patch for this for
> Tegra U-Boot already.
> 
> > 2) Indicate in device tree if linux is booting in secude mode or non-secure
> >    mode.
> > 3) Use this information in the kernel to decide how to apply the WARs for
> >    secondary core bringup and after powerungating.
> 
> Hmmm. That seems like a lot of overhead to avoid duplicating roughly 8
> assembly instructions per Tegra version. Also, some/all of the WARs in

Unfortunately we can't write to the diag register if we are in non-secure
mode. So unless we never want to support running in non-secure mode, we will
need to make the distinction somehow and use a different method for non-secure
mode. Or assume the secure OS has applied the WARs. I'm afraid existing secure
OS implementations for Tegra don't work that way though. They just offer an
SMC which allows the kernel to read and write the diag register.

> question probably need to be applied very early by assembly code, e.g.
> before MMU is re-enabled, so I think you'd end up parsing DT from
> assembly again, which would be painful. I tend to think just including
> the code in the kernel's SoC-specific reset handler is simplest, and
> even with the slight duplication, probably most maintainable. I've
> written a patch for this for Tegra already, which I hope to post later
> today, depending on testing and what other stuff I get side-tracked on.

No. We could just set a flag in __tegra_cpu_reset_handler_data based on the
info in DT or use a different reset handler. DT is parsed before bringing up
secondary CPUs, so this approach should work I think.

Cheers,

Peter.