On 6.04.2015 18:40, Tony Lindgren wrote:
* Tony Lindgren <tony@xxxxxxxxxxx> [150406 08:24]:
* Matthijs van Duin <matthijsvanduin@xxxxxxxxx> [150405 16:53]:
Cortex-A8 errata doc states in its workaround for erratum 430973:
By default, the BTB Invalidate instruction is treated as a NOP on Cortex-A8.
However, it is possible to enable the BTB Invalidate instruction such that it
actually does a full invalidate of the BTB by setting the IBE bit (bit 6) in
the CP15 Auxiliary Control Register. As a consequence of erratum 687067, the
L1 System Array Debug Register should be cleared to 0 before the IBE bit is
set using the following code sequence:
MOV r1, #0
MCR p15, 0, r1, c15, c1, 0 ; write instruction data 0 register
MRC p15, 0, R1, c1, c0, 1 ; read Aux Ctl Register
ORR R1, R1 #(1 << 6) ; set IBE to 1
MCR p15, 0, R1, c1, c0, 1 ; write Aux Ctl Register
The above code needs to be executed in Secure state. ARM Limited recommends
that this code is added to the boot monitor.
The 430973 workaround code in proc-v7.S will do absolutely nothing if
executed in non-secure state. Ditto for the 458693 workaround, and the
460075 workaround should trigger an undefined instruction exception.
Maybe linux is started in secure mode on some targets and this code
was written for one of those?
That's only for HS omaps, for those we currently only do it in the
nokia_n900_legacy_init that calls rx51_secure_update_aux_cr.
I scanned DM814x secure ROM for any (ARM or Thumb) write to
Instruction L1 System Array Debug Register 0, but I found none, hence
my warning to watch out for erratum 687067.
OK
Adding the full set of BTB invalidates while making sure IBE is
disabled on sufficiently recent Cortex-A8 revisions would be optimal
for the Cortex-A8. But, apparently (based on the description of the
ARMv7 CPUID registers) there are also processors which only require
BTB invalidates when code is modified, but not when context-switching,
so there may be performance considerations there...
Attempting to summarize all that's been discussed.. It sounds like we
need the following implemented:
1. For cortex-a8 revisions affected by 458693, we can do a custom
cpu_v7_switch_mm function that always does flush BTAC/BTB.
2. For HS cortex-a8 processors other than n900 affected by 458693,
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 458693, we need
to clear IBE bit to avoid erratum 687067.
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?
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
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.
Regards,
Tony
Regards,
Ivo
--
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
