Date: Fri, 11 Dec 2015 18:02:15 +0200 From: Stanislav Galabov <sgalabov@gmail.com> To: freebsd-mips@freebsd.org Subject: MIPS_CONFIG0_VI defined wrong in sys/mips/include/cpuregs.h? Message-ID: <7514D462-9B7F-4728-8784-135614215992@gmail.com>
next in thread | raw e-mail | index | archive | help
Hi all, It seems that MIPS_CONFIG0_VI is defined wrong in = sys/mips/include/cpuregs.h. According to MIPS=C2=AE 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=E2=80=99s 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=E2=80=99ve 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=E2=80=99s = detected as virtual when it actually isn=E2=80=99t) on kernels that use = CCA >=3D 0x4 for Kseg0, which, in turn, leads to a lot of fun trying to = figure out what=E2=80=99s 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=E2=80=99s necessary). I would do it myself if I but I have no = commit privileges. Best wishes, Stanislav=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7514D462-9B7F-4728-8784-135614215992>