failing to convert from JH7100 / VisionFive 1 DTS in U-Boot

[orangecms]

I'm trying to get an SVD from https://github.com/starfive-tech/u-boot/blob/07eac31890155be6005237cecdc1871d471c86c7/arch/riscv/dts/jh7100-visionfive.dts - failing in any of the following ways:

Passing the DTS to cmsis-svd-generator errors when facing the #include statements, yielding parser errors.

So I tried preprocessing with cpp, which errors when encountering & characters.

So I compiled again to a flat tree using dtc, and then got parser errors again for the / in the beginning already (/ { is how a tree starts).

For details, please see the Gist with more notes:
https://gist.github.com/orangecms/2d014eb3a21123b4da89d13f974f7c6b

[orangecms]

Note: Similar to #15, it does work when I take the VisionFive DTS from Linux. However, the result is useless, almost empty:

<?xml version="1.0" encoding="utf-8"?>
<device schemaVersion="1.3" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="CMSIS-SVD.xsd">
  <name>StarFive VisionFive V1</name>
  <version>0.1</version>
  <description>From StarFive VisionFive V1,model device generator</description>
  <addressUnitBits>8</addressUnitBits>
  <width>32</width>
  <size>32</size>
  <access>read-write</access>
  <peripherals>
  </peripherals>
</device>

[rmsyn]

@orangecms This tool is pretty specific to SiFive stuff, and looks up regmap SVD definitions based on the base name in DTS.

Educated guess is that because the name in the DTS is "StarFive" and not "SiFive", none of the regmaps are found.

The tool also looks up entries based on the reg-names child node, so if that is not present in the DTS, no peripheral entry is created.

Currently working on a fix to have this tool parse DTS for boards based on SiFive SoCs, and hopefully generalize to work with regmaps for non-SiFive based products.

Probably going to mean manually, or some other way, building those regmap SVD files, and adding them to the lookup path.

That DTS in your original post also doesn't contain a soc child node, which is what this tool uses to build the peripherals entry.

[orangecms]

@orangecms This tool is pretty specific to SiFive stuff, and looks up regmap SVD definitions based on the base name in DTS.

Educated guess is that because the name in the DTS is "StarFive" and not "SiFive", none of the regmaps are found.

The tool also looks up entries based on the reg-names child node, so if that is not present in the DTS, no peripheral entry is created.

Ah, gotcha... So the tool is essentially only useful for peripherals it knows, and the StarFive ones are mostly not among them. :/
I was hoping to at least get a rough scaffolding.

Currently working on a fix to have this tool parse DTS for boards based on SiFive SoCs, and hopefully generalize to work with regmaps for non-SiFive based products.

Oh cool, thank you!

That DTS in your original post also doesn't contain a soc child node, which is what this tool uses to build the peripherals entry.

Yea that makes sense. I wasn't that familiar with DT when I tried this.
I may have another look now. Thanks for the hints!

[rmsyn]

I also had better luck by running the C preprocessor over the DTS file before passing to generate_svd.py:

cpp -E -P -Wp,-I<include-dir> /path/to/some.dts > processed.dts

• -E tells it to only run the preprocessor
• -P for it not being a C file
• -Wp,-I<include-dir> to point to the include directory for any C headers included by the DTS

Still going to run into issues with DTS files used in Linux, since they seem to use the ranges; field before peripheral entries, instead of a reg-names child node. May just have to make a manual edit, and keep/update the patched file, though it would be nicer to do all of this automatically.

Edit: so, I got a little further with parsing: rmsyn/generalize-dts-parser

It mostly works, and can generate a rough SVD from this DTS:
th1520-beaglev-ahead.dts.tar.gz

Still working on regmap definitions. Basically, for DTS that include a SoC DTSI file with register definitions, we should be able to directly create the register map from the /cpu path.

[grinux]

Still working on regmap definitions. Basically, for DTS that include a SoC DTSI file with register definitions, we should be able to directly create the register map from the /cpu path.

Hi @rmsyn! Is there any progress with that? :)

[rmsyn]

Helllo @grinux, there is progress. You can follow my current work in either the open PR: #19, or the fork branch I try to update similarly: https://github.com/rmsyn/cmsis-svd-generator/tree/dev

Currently, I am debugging an issue with the generated jh71xx-pac library blowing up the binary size of a relative simple flashloader crate: https://github.com/rmsyn/starfive-flashloader

You'll also probably need to edit some names in DTS files that may not be valid identifiers in whatever language you're building a peripheral access library (e.g. plic_5.0.0 is not a valid identifier in Rust). This is probably something that can be addressed in a generic way, but for now editing the DTS manually is easier.

So, it works, but I'm still working out some errors. Most come from parsing spec sheets, and driver implementations in other projects. 😬