MIPS_CONFIG0_VI defined wrong in sys/mips/include/cpuregs.h?

[Warner Losh]

Comitted.

On Fri, Dec 11, 2015 at 9:46 AM, Stanislav Galabov <sgalabov at gmail.com>
wrote:

> Hi Adrian,
>
> Done:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205249
>
> Best wishes,
> Stanislav
>
> > On Dec 11, 2015, at 18:38, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> >
> > Hm,
> >
> > Would you file a freebsd pr about it? I'll go take a look at it and fix
> it up.
> >
> > I'll go review the more recent mips core docs and see what's going on
> too.
> >
> > Thanks!
> >
> >
> > -a
> >
> >
> > On 11 December 2015 at 08:02, Stanislav Galabov <sgalabov at gmail.com>
> wrote:
> >> Hi all,
> >>
> >> It seems that MIPS_CONFIG0_VI is defined wrong in
> sys/mips/include/cpuregs.h.
> >>
> >> 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.
> >>
> >> Best wishes,
> >> Stanislav
> >> _______________________________________________
> >> freebsd-mips at freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> >> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>