SVD files: Vanilla or not?

[dbrgn]

There are two approaches to managing SVD files:

• We can commit the original SVD file to the PAC directory and apply patches when generating the bindings
  • Variant: Only download the SVD on demand (risk: it could be offline)
• We can patch the SVD file directly in the repository and commit the fixes

The latter is basically the same as the former, but instead of using diff and patch to apply the patches, we use git. The applied patches can then be listed using git log. The only prerequisite for this is that the vanilla SVD file is committed before the patches are applied.

What are your opinons, @hannobraun and @rnestler? I tend towards the second approach, simply patching the SVD file directly and committing the result. It leads to less work when generating the bindings, since patches have already been applied.

[hannobraun]

I totally agree with you. If possible, we should commit the SVD files and directly patch them in the repository. However, that requires the SVD file to be available under a license that permits distribution, which is not the case for the LPC82x file I'm using. This is the only reason I've chosen the download-and-patch approach.

The newer SVD files from NXP (available via the MCUXpresso SDK Builder) are BSD-licensed, from what I've seen. This is good, but the LPC82x ones are so buggy, I decided against using them [1][2].

[dbrgn]

Hm, can hardware description files fall under copyright? After all it is just a mechanical description. Of course the files are covered by NPX's IP, but that's something different than copyright.

[hannobraun]

That's a good point, but I don't know enough about copyright to answer that question. I decided to play it safe, especially since the file contains an explicit notice about copyright. Although I'd be surprised, if NXP decided to sue us over this crappy, old SVD file :)