* Ivaylo Dimitrov <ivo.g.dimitrov.75@xxxxxxxxx> [150406 10:15]: > 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? Executing them as nop is Cortex-A8 specific. On other ARMv7 CPUs, BTB invalidation on context switch may be unnecessary yet expensive. In general I think you'll want a version with and one without BTB flushing, and select depending on CPUID (ID_MMFR1, bits 28-31), with overrides for known processor issues (i.e. the cortex-a8 has a wrong value there in all cases: it reports value 2, while it should be treated as 1 or 4 depending on cpu revision). On 6 April 2015 at 19:42, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > 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.. That sounds.... really odd. The TRM is fairly explicit about BTB flush executing as nop when IBE is not set. Of course the TRM is not exactly flawless, but still... >> 2. For Cortex-A8 revisions affected by 430973, set IBE bit to 1, set it >> to 0 for all others. Note btw that erratum 687067 affects *all* Cortex-A8 revisions, so there's a bit of a catch-22 there. The proper workaround for it (zeroing some particular debug register) can only be done in secure privileged mode, and there's no straightforward way to check whether this has been done. However, it only affects BTB invalidate by MVA, afaik BTB invalidate all is safe. >> That should happen as soon as possible, >> otherwise kernel may crash on affected revisions if thumb-compiled. The right place to do this to be honest would be in the bootloader, but I guess that's not always convenient to arrange... Matthijs -- 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
