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