ARM errata 430973 on multi platform kernels

Tony Lindgren tony at atomide.com
Mon Apr 6 10:42:45 PDT 2015


* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [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.

Regards,

Tony



More information about the linux-arm-kernel mailing list