Page MenuHomeFreeBSD

riscv: support new "riscv,isa-extensions" string-array
AcceptedPublic

Authored by br on Thu, Oct 1, 6:13 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 3, 3:50 AM
Unknown Object (File)
Fri, Oct 2, 5:37 PM
Unknown Object (File)
Fri, Oct 2, 1:24 PM
Unknown Object (File)
Thu, Oct 1, 10:17 PM
Subscribers

Details

Reviewers
mhorne
bnovkov
Group Reviewers
riscv
Summary

Support the new "riscv,isa-extensions" property on RISC-V hart nodes in FDT.

The "riscv,isa" property is deprecated, but cannot be removed because doing so would break compatibility with existing DTBs. The new properties replace it: "riscv,isa-base" describes the base ISA and "riscv,isa-extensions" is a string array containing the supported ISA extensions.

See
https://github.com/torvalds/linux/commit/aeb71e42caae2031ec849a858080d81462cacca9
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/riscv/extensions.yaml

The "riscv,isa-extensions" property can be relatively large; on the Spacemit K3 it is approximately 300 bytes.

The FreeBSD OFW interface does not provide access to the underlying FDT property data without copying it, and memory allocation is not possible this early. So allocate a static buffer for the property instead.

Reuse the existing parse_riscv_isa() implementation to parse both the new extension property and the legacy "riscv,isa" property.

Test Plan

Tested in QEMU and Spacemit K3.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

br requested review of this revision.Thu, Oct 1, 6:13 PM
br created this revision.

Thanks! I have a half-baked implementation of this and I encountered the same issue with OFW interface. There are useful functions implemented by libfdt which we cannot use, e.g. fdt_stringlist_get(). I wondered about what a change to the OFW interface would look like to accommodate something like this...

(In the end, it is not so important 😆 )

sys/riscv/riscv/identcpu.c
409

You could use isa_extensions[] here too to hold the result. It is harmless either way.

468–472
This revision is now accepted and ready to land.Fri, Oct 2, 2:07 PM
bnovkov added a subscriber: bnovkov.

LGTM, one minor inline comment aside.

sys/riscv/riscv/identcpu.c
415

I know that this was carried over from the previous implementation, but I think this should be turned into an explicit panic.
Same thing goes for the KASSERT in parse_isa_extensions.