* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [150407 06:58]: > On Mon, Apr 06, 2015 at 10:42:45AM -0700, Tony Lindgren wrote: > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@xxxxxxxxx> [150406 10:15]: > > > On 6.04.2015 18:40, Tony Lindgren wrote: > > > > > > > >Oops sorry, wrong numbers for errata above.. s/458693/430973/, here's > > > >a better version: > > > > > > > >1. For cortex-a8 revisions affected by 430973, we can do a custom > > > > cpu_v7_switch_mm function that always does flush BTAC/BTB. > > > > > > > > > > Why custom function, if IBE bit is zero, BTB invalidate instruction is a > > > NOP. Do you think that "mcr p15, 0, r2, c7, c5, 6" executed as a NOP will > > > put so much overhead, that it deserves a custom function? > > > > Hmm but it still seems to do something also on cortex-a8 r3p2 that > > is supposedly not affected by 430973.. Based on my tests so far, at least > > armhf running cpuburn-a8 in the background and doing apt-get update > > segfaults constantly without flush BTAC/BTB. This seems to be the case > > no matter how the aux ctrl reg bits are set.. This should be reproducable > > on any pandboard xm BTW. > > > > > >2. For HS cortex-a8 processors other than n900 affected by 430973, > > > > we need to implement functions similar to rx51_secure_update_aux_cr, > > > > the bootrom on n900 is different from TI HS omaps so the SMC call > > > > numbering may be different. > > > > > > > >3. For later cortex-a8 processors not affected by 430973, we need > > > > to clear IBE bit to avoid erratum 687067. > > > > > > > > > > Maybe it should be implemented something like: > > > > > > 1. if Cortex-A8, always execute invalidate BTB instruction in > > > cpu_v7_switch_mm > > > > This part still seems to need more investigating for why it's still > > needed also r3p2 as I describe above. Otherwise we may be hiding some > > other bug. > > > > > 2. For Cortex-A8 revisions affected by 430973, set IBE bit to 1, set it > > > to 0 for all others. That should happen as soon as possible, > > > otherwise kernel may crash on affected revisions if thumb- > > > compiled. > > > > Yes this makes sense. > > Well, one thing we can do is to tweak the proc-v7*.S such that we detect > Cortex-A8 separately, and only execute the BTB flush for CA8 processors > if the errata is enabled. Something like this (untested): > > --- a/arch/arm/mm/proc-v7.S > +++ b/arch/arm/mm/proc-v7.S > @@ -527,6 +545,16 @@ __v7_ca9mp_proc_info: > __v7_proc __v7_ca9mp_proc_info, __v7_ca9mp_setup, proc_fns = ca9mp_processor_functions > .size __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info > > + /* > + * ARM Ltd. Cortex A8 processor. > + */ > + .type __v7_ca8_proc_info, #object > +__v7_ca8_proc_info: > + .long 0x410fc080 > + .long 0xff0ffff0 > + __v7_proc __v7_ca8mp_proc_info, proc_fns = ca8_processor_functions > + .size __v7_ca8_proc_info, . - __v7_ca8_proc_info > + > #endif /* CONFIG_ARM_LPAE */ > > /* Works for me. The above needs the following fix folded in to build: --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -532,7 +532,7 @@ __v7_ca9mp_proc_info: __v7_ca8_proc_info: .long 0x410fc080 .long 0xff0ffff0 - __v7_proc __v7_ca8mp_proc_info, proc_fns = ca8_processor_functions + __v7_proc __v7_ca8_proc_info, __v7_setup, proc_fns = ca8_processor_functions .size __v7_ca8_proc_info, . - __v7_ca8_proc_info #endif /* CONFIG_ARM_LPAE */ Regards, Tony -- 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
