Hello Maciej & Paul,
在 2020/8/22 上午10:29, Maciej W. Rozycki 写道:
Hi Paul,
FAOD <cpu-feature-overrides.h> is not a hack, but an optimisation measure
so that features known to be hardwired for a given machine/CPU do not have
to be dynamically queried every time referred. In some cases that results
in large portions of code being optimised away by the compiler as well.
Fair enough. Bloat-o-meter reports about ~100 KiB saved when that file is
present. But we can't use it in a generic kernel, unfortunately.
Well, run-time patching might be an alternative to get the best of both
worlds, but someone would have to reimplement our feature selection system
to use it.
The hardcoded value for a feature defined in <cpu-feature-overrides.h>
always has to be the same as one in the corresponding bit of the `options'
member of `struct cpuinfo_mips', in this case MIPS_CPU_TLBINV.
In theory yes, in practice the CPU detection code is lagging behind...
I wasn't aware of that. In that case it has been a design abuse which
has been missed by the maintainer when accepting patches. It used to be
the case that run-time detection was accurate and overrides were rather
lazily added.
Also I note Ingenic must have had a CPU erratum if our `decode_configs'
doesn't just work, as the interpretation of CP0.Config[5:0] registers has
been architectural and mandatory, and that for a reason. It's only legacy
MIPS I-IV processors that should require special attention here.
I think I found the cause of the problem. Ingenic XBurst2's TLBINV is
operate on entire MMU, according to the description of the MD00090
document, the IE value in cp0 config4 should be 3 (Ingenic's XBurst2
Core PM document also shows that the IE value is indeed 3). But the code
in cpu-probe.c only detects the case where the IE value is equal to 2
(TLBINV only operate on one TLB entry). Therefore, the kernel mistakenly
believes that X2000 does not support TLBINV during detection.
Thanks and best regards!
Maciej
