svdtools icon indicating copy to clipboard operation
svdtools copied to clipboard

svdtools: patching yaml files/multipart yaml conversion?

Open hanetzer opened this issue 3 years ago • 4 comments

So, I know this is mostly used to patch vendor-shipped svd files, but as prior issues have stated, I've been using this to write svd's for cortex-a socs in yaml for use in other projects (ghidra, pycortexmdebug, etc).

Is it possible, for example, do do the patching type stuff without a 'real' 'seed' svd file? Like, I'd want to define all the svd blocks for stuff that is unique to this particular soc (clock controllers, system controllers, various glue peripherals) in the primary yaml file, and draw from various 'library' yaml files that define 'standard' peripherals (arm primecell stuff, designware stuff, etc).

I realize I can just concatenate main.yaml, gpioX.yaml, and so on, but that gets awkward as time goes on and the file grows.

For example, one could have a file tree like this:

.
├── hi3516dv300.yaml
├── hi3521av100.yaml
└── peripherals
    ├── designware
    │   └── dw-mmc.yaml
    └── primecell
        ├── pl011.yaml
        ├── pl061.yaml
        └── sp804.yaml

Where hi3516dv300.yaml defines that there is a pl061 gpio at every 0x120d_{0..b}000 address block but hi3521av100 has them at 0x12{15..22}_0000 and so on?

hanetzer avatar Sep 08 '22 02:09 hanetzer

Currently there's no option to generate an svd entirely from scratch, because each "device" top-level yaml file requires an _svd key. I think that requirement could be weakened to start with an empty SVD if none is specified, which is hopefully fairly easy to do and I'd find it useful too.

For the YAMLs, you can _include as many YAML files as you want, which can each include more files, as we do here - so there shouldn't be any need to concatenate them yourself. However, there's no way to do a "parameterised include" where you specify the base address to use. Right now I think the simplest way to accomplish that is for the file you include to not specify an address, or specify a standard common one, and the top-level device file can easily modify it to be whatever address is required.

adamgreig avatar Sep 08 '22 10:09 adamgreig

hmm... maybe do that thing you guys did with "GPIO*" inclusion, and only include the baremost data in the 'seed' svd to set base address and interrupt?

hanetzer avatar Sep 08 '22 10:09 hanetzer

svdtools patch was created and optimized for patching existent files. I don't think it is good idea to use same syntax for other tasks like creating new files. There are alternatives you could use:

  1. svd-rs supports serde. So you can create SVD-like files in yaml (json) syntax if you don't like XML and then convert them with svdtools convert if it is needed. So you can write wrapper which merge peripheral files in one SVD-like and then serde it.
  2. Use non-SVD alternatives like embassy metapack.

burrbull avatar Sep 09 '22 08:09 burrbull

Another idea: have the same syntax for the primary patch yaml file (the one that includes the svd file), but allow for using a yaml file as the 'seed' svd?

hanetzer avatar Sep 09 '22 22:09 hanetzer