Running valgrind on an executable (n64 little endian) linked against openblas gives:
vex mips->IR: unhandled instruction bytes: 0x3B 0x10 0x10 0x7C
==9377== valgrind: Unrecognised instruction at address 0x4aa6dd8.
==9377==    at 0x4AA6DD8: ??? (in /usr/lib/libopenblas_mipsp-r0.2.19.so)
==9377==    by 0x4AA6D98: ??? (in /usr/lib/libopenblas_mipsp-r0.2.19.so)
==9377== Your program just tried to execute an instruction that Valgrind
==9377== did not recognise.  There are two possible reasons for this.
==9377== 1. Your program has a bug and erroneously jumped to a non-code
==9377==    location.  If you are running Memcheck and you just saw a
==9377==    warning about a bad jump, it's probably your program's fault.
==9377== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9377==    i.e. it's Valgrind's fault.  If you think this is the case or
==9377==    you are not sure, please let us know and we'll try to fix it.
==9377== Either way, Valgrind will now raise a SIGILL signal which will
==9377== probably kill your program.
==9377==
==9377== Process terminating with default action of signal 4 (SIGILL): dumping core
==9377==  Illegal opcode at address 0x4AA6DD8
==9377==    at 0x4AA6DD8: ??? (in /usr/lib/libopenblas_mipsp-r0.2.19.so)
==9377==    by 0x4AA6D98: ??? (in /usr/lib/libopenblas_mipsp-r0.2.19.so)

This instruction is:
 1bedd8:       7c10103b        rdhwr   s0,hwr_cc

I see from the sources there is no support for reading the cycle counter using rdhwr (rd == 2). Given that there is already support for reading the Cavium specific count register, it would seem logical to add support for reading the generic MIPS one.

I expect you want to implement reading the ccres register to go with this (rd == 3). The ISA manual states that all R2 processors support these registers.