According to MIPS® Architecture For Programmers Volume III, page 149, Figure 9-29 (Config Register Format), accessed via http://www.t-es-t.hu/download/mips/md00090c.pdf, bit 3 of config0 is supposed to be VI (Virtual Instruction Cache), while the current definition of MIPS_CONFIG0_VI (0x00000004) implies that it’s bit 2. This leads to a lot of headaches when trying to bring up a new CPU (1004KC in my case) and trying to use Cachable-Coherent CCA (0x5 or 0b101) for Kseg0 :-) I guess we’ve been able to get away with this so far due to mainly 2 things: 1. CPUs that use CCA 0x4 - 0x7 for Kseg0 usually are cache-coherent anyway, so their cache ops are most likely no-op. 2. CPUs that use CCA 0x0 - 0x3 for Kseg0 work just fine, as bit 2 is not set :-) This leads to improper detection of the I-Cache type (it’s detected as virtual when it actually isn’t) on kernels that use CCA >= 0x4 for Kseg0, which, in turn, leads to a lot of fun trying to figure out what’s wrong and why things work with CCA 0x3 and not with 0x5 on a single core... After changing the definition of MIPS_CONFIG0_VI from 0x00000004 to 0x00000008 everything goes back to normal even with CCA 0x5. I would appreciate it if someone would commit this change (if you guys think it’s necessary). I would do it myself if I but I have no commit privileges.
A commit references this bug: Author: imp Date: Fri Dec 11 16:51:04 UTC 2015 New revision: 292114 URL: https://svnweb.freebsd.org/changeset/base/292114 Log: Correct the CONFIG0_VI value. According to http://www.t-es-t.hu/download/mips/md00090c.pdf this is bit 3 of the config0 word, not bit 2. This should fix virtually indexed caches (relatively new in the MIPS world, so no current platforms used this and current code just uses it as an optimization). It was causing false positives on newer platforms that default to large values for the kseg0 cache coherency attribute. Submitted by: Stanislav Galabov PR: 205249 Changes: head/sys/mips/include/cpuregs.h