Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

svdtools: patching yaml files/multipart yaml conversion? #126

Open
hanetzer opened this issue Sep 8, 2022 · 4 comments
Open

svdtools: patching yaml files/multipart yaml conversion? #126

hanetzer opened this issue Sep 8, 2022 · 4 comments

Comments

@hanetzer
Copy link

hanetzer commented Sep 8, 2022

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?

@adamgreig
Copy link
Member

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.

@hanetzer
Copy link
Author

hanetzer commented Sep 8, 2022

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?

@burrbull
Copy link
Member

burrbull commented Sep 9, 2022

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.

@hanetzer
Copy link
Author

hanetzer commented Sep 9, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants