riscv: rework CPU identification [1/6]

[mhorne]

Summary

Make better use of the RISC-V identification CSRs: mvendorid, marchid,
and mimpid.

This code was written before these registers were well-specified, or
even available to the kernel. It currently fails to recognize any CPU or
platform.

Per the privilege specification, mvendorid contains the JEDEC vendor ID,
or zero.

The marchid register denotes the CPU microarchitecture. This is either
one of the globally allocated open-source implementation IDs, or the
field has a custom encoding. Therefore, for known vendors (SiFive) we
can also maintain a list of known marchid values. If we can not give a
name to the CPU but marchid is non-zero, then just print its value in
the report.

The mimpid (implementation ID) could be used in the future to more
uniquely identify the micro-architecture, but it really remains to be
seen how it gets used. For now we just print its value.

Test Plan

dmesg output after the whole series of changes on the HiFive Unmatched:

CPU 0  : Vendor=SiFive Core=6/7/P200/X200-Series Processor (Hart 2)                            
  marchid=0x8000000000000007, mimpid=0x20181004                                                
  MMU: 0x1<Sv39>                                                                               
  ISA: 0x112d<Atomic,Compressed,Double,Float,Mult/Div>

and in QEMU:

CPU 0  : Vendor=Unspecified Core=Unknown (Hart 0)
  marchid=0x70232, mimpid=0x70232
  MMU: 0x3<Sv39,Sv48>
  ISA: 0x112d<Atomic,Compressed,Double,Float,Mult/Div>

[jrtc27]

sys/riscv/include/cpu.h

81

UCAM would be a more helpful abbreviation (and one that the University uses) lest it be confused with the University of California as a whole

sys/riscv/riscv/identcpu.c

96

What made you choose this rather than U7-series? Is there some official document somewhere that refers to this marchid by this name?

106

Perhaps we want a 0 -> "Unspecified", either here or in the function? That distinguishes it from some vendor we don't know about but is specified. Especially since 0 is what you have to use as a non-commercial entity.

345

No T-Head despite the define?

347

In the arm64 world the table stores a pointer to the vendor's parts in the vendor entry rather than splitting them like this, which makes things shorter. Is there a reason you opted not to do that? Doing zero-terminated lists rather than using nitems helps make that less ugly, too.

380–384

arm64 does %3u so things line up nicely when you roll into the multiple digits (provided MAXCPU remains < 1000). arm64 also prints a one-line summary for each core and will print out detailed information if it differs from the previous core (or bootverbose is set), which all seems useful to me. It seems like we should be able to squeeze the basic identification information into a single line like it, too? Then the ISA etc information can be following lines like it does and collapsed when the same for non-bootverbose. In general we should be aligning with other similar ports like arm64 where possible.

[mhorne]

sys/riscv/riscv/identcpu.c

96

Yes, in the U74 Core Complex manual, Appendix B, they describe the encoding of marchid and this is the exact string specified.

345

*shrug* we do not run on it, and I did not chase down any marchid values. Arguably I don't need to add the T-Head vendor entry for the same reason, but I had that information and it will not change.

347

Earlier iterations were zero-terminated, and for reasons forgotten I shuffled it around. I agree it is cleaner so I will restore that.

380–384

Sure, I will play around with the format a bit more.

I did not look too much at other identcpu code, purposefully. How this code should look ends up being quite an open-ended problem. I really tried to approach it by assessing the needs and mechanisms of this platform in particular.

I think the arm64 print-only-when-different behaviour is superior, so I will work on that. It will be in a future change, though, since this one is really just about printing more complete information than we currently do, based on what is now available.

[mhorne]

Rework the change a bit based on review comments.

Provide a better summary line (see Test Plan).