* Tony Lindgren <tony@xxxxxxxxxxx> [150413 07:46]: > * Jeroen Hofstee <linux-arm@xxxxxxxxxxxxx> [150411 02:26]: > > Hello Russell, +Tony, > > > > Thanks for taking the time to respond, > > > > On 11-04-15 09:52, Russell King - ARM Linux wrote: > > >On Fri, Apr 10, 2015 at 11:29:13PM +0200, Jeroen Hofstee wrote: > > >>On 25-02-15 20:36, Jeroen Hofstee wrote: > > >>>On 09-12-14 14:30, Jeroen Hofstee wrote: > > >>>>From: Jeroen Hofstee <linux-arm@xxxxxxxxxxxxx> > > >>>> > > >>>>Update the list of revisions subject to this errata. > > >>>> > > >>>>Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > > >>>>Cc: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > >>>>Cc: Andreas Bießmann <andreas.devel@xxxxxxxxxxxxxx> > > >>>>Signed-off-by: Jeroen Hofstee <jhofstee@xxxxxxxxxxxxxxxxx> > > >>>>--- > > >>>>I don't have access to the AT400/AT401/AT490 document, but > > >>>>Andreas was kind enough to provide this information, see > > >>>>https://www.mail-archive.com/u-boot@xxxxxxxxxxxxx/msg156620.html > > >>>> > > >>>>Resending from an address which is subscribed to the ML... > > >>>>--- > > >>>> arch/arm/Kconfig | 2 +- > > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >>>> > > >>>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > >>>>index 89c4b5c..a2202fa 100644 > > >>>>--- a/arch/arm/Kconfig > > >>>>+++ b/arch/arm/Kconfig > > >>>>@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 > > >>>> depends on CPU_V7 > > >>>> help > > >>>> This option enables the workaround for the 430973 Cortex-A8 > > >>>>- (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb > > >>>>+ (r1p0..r1p3, r1p7) erratum. If a code sequence containing an > > >>>>ARM/Thumb > > >>>> interworking branch is replaced with another code sequence at > > >>>>the > > >>>> same virtual address, whether due to self-modifying code or > > >>>>virtual > > >>>> to physical address re-mapping, Cortex-A8 does not recover from > > >>>>the > > >>> > > >No. If you read the discussion that the OMAP people are having, it is > > >unclear whether r3p2 is actually affected by this errata or not. > > I scanned through it, but that is a different issue it seems. This patch > > only adds r1p3 and r1p7 to the documentation, since according to ARM > > they are affected by this errata. Newer revision should not be affected > > by this errata (or ARM reintroduced it). > > > > The patch is _not_ adding r3p2 as an affected version. And is also not > > about how to deal with cores no longer needing this workaround. > > Right.. But it seems that having the aux ctrl register bit enabled > without doing the flush btac part leads into a different set of > issues. > > > >In the discussion with OMAP people, we've come up with a potentially > > >better solution to this, which is to rearrange the code so that only > > >Cortex-A8 executes this workaround, and the BTB flush is always > > >present (which Tony says fixes the problem.) > > > > The am3517 / r1p7 is a Cortex-a8 and is affected by this errata. I fail to > > see why making this cortex-a8 specific will help anything about the revision > > not being mentioned in the help text. (unless the CONFIG option gets > > completely > > removed). > > >Meanwhile, OMAP people are seeing about updating uboot to set/clear > > >the auxiliary control register bit appropriately for the revision of > > >the core. > > Well almost appropriately. [1] suggest "the bootloaders can be fixed > > Cortex-A8 > > revisions later than r1p2 to not set the IBE bit.". That should have been > > r1p7 as > > well. > > > > >In any case, adding the patch and suggesting people enable this for > > >more Cortex-A8's (eg, non-OMAP) won't actually do anything in a > > >multiplatform kernel. > > > > > Can you give an example of a r1p7 not needing the workaround? > > Do you have some pointer for the documentation mentioning r1p7 is > affected? It is possible that the revision range is wrong.. But I'm > more likely to believe it is correct and we're hitting a different > problem. > > I'm hoping that with Russell's patch and my patch in the thread > below, you don't necessarily need to enable 430973. That's these > two patches: > > http://www.spinics.net/lists/arm-kernel/msg411433.html > http://www.spinics.net/lists/arm-kernel/msg411038.html > > If what Russell and I are saying is correct, with the above two > patches your system should behave properly with 430973 even if > bit 6 in the aux ctrl register is set (or unset) by the bootloader. > > If r1p7 is behaves with bit 6 cleared and errata 430973 set, then > we know r1p7 is unaffected by 430973. Sorry let's take this part again: If r1p7 is behaves with bit 6 cleared and errata 430973 _unset_, then we know r1p7 is unaffected by 430973. Regards, Tony > > http://www.spinics.net/lists/arm-kernel/msg411297.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
