Add PMP granularity to DTS

[khannaudit]

Add riscv,pmpgranularity parameter to device tree string; property name inspired by riscv/riscv-isa-sim DTB parser.
https://github.com/riscv/riscv-isa-sim/blob/ecc039ef5726315b7e37e8a9c7b682bbe09c9cf5/riscv/dts.cc#L270

Observed the following output in a custom configuration:

riscv,isa = "rv32imac";
riscv,pmpgranularity = <4>;
riscv,pmpregions = <4>;

Type of change: other enhancement

Impact: no functional change | API addition (no impact on existing code)

Development Phase: implementation

[khannaudit]

@aswaterman request for review

[aswaterman]

What's the rationale for adding this to DTS when it can be determined by software in a few instructions? If it's not for target software, it can just go in OM instead, right?

[khannaudit]

You're right in that it's not for target software, rather it is for verification (to make sure that those instructions report the correct granularity to target software, and to run appropriate tests). However, OM is not a standard interface that tools like riscv-isa-sim consume, so I had to go this way. I was soon also going to do similar PRs for things like S-mode-without-VM

I can look into adding this information to DTS via our private codebase wrappers around rocketchip.BaseTile, or I can build custom OM parsers around riscv-isa-sim. Any preference/objection to either?

[aswaterman]

DTS is clearly the path of least resistance, and importing a nonstandard description language into Spike is undesirable.

My main concern here is that sometimes DTB is encoded in a ROM, and so these additions translate to (minor) incremental HW cost. If we think there won't be dozens of them, I think putting them into DTS is OK.

I suppose another middle ground is to subset the DTS that actually gets baked into ROM: we could mark certain properties as being redactable or something.

[khannaudit]

Please merge as I don't have write access.