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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
