Browse Source

more stuff in the README

Triss 4 months ago
  1. 51


@ -23,3 +23,54 @@ MMIO register definition files.
* DSLite → SVD [*planned*]
* SVD → DTS/DTB (peripherals only) [*planned*]
* DTS/DTB → SVD (peripherals only) [*planned*]
## Usage
#### Libraries
* `dvf/` is able to parse DVF files
* `svd/`, `svd/`, `svd/` handle SVD files
#### Utilities
* `dvf/` is a quick DVF-to-headerfile converter
* `` converts DVF to SVD files using the above libraries
## Dependencies
Python stdlib only, though I've been using 3.10, it might be the case that some
things aren't in eg. 3.6.
## FAQ etc
#### Why is it Python? Why is the Python code so hacky?
I quickly wanted to get something to work so that I could import MMIO stuff in
Ghidra. Yes the code could be cleaner/faster (especially with a resp. Racket or
Rust rewrite), but I just wanted to Get Things Done.
#### Why is it not a proper Python module?
I started from a script and things evolved from there. I should probably
restructure the codebase a bit, the current method of importing stuff (by
adding things to the Python module path...) is, not a good idea.
#### Why are the converters inaccurate?
For DVF, the main problem lies in the file format: all registers are laid out
without peripheral associations, so no peripheral information (and peripheral ↔
interrupt) mapping is available. Furthermore, the file format is binary, so
figuring out which exact bits correspond to which register properties (eg.
'write-to-clear') is pretty hard. The basics are still there, though. The code
is currently untested for V830 and RX DVF files, which might differ in some
For TRACE32 PER, a large problem is that these files mix UI elements,
conditionals and loops, and actual peripheral and register definitions, in a
quite shitty to parse text-based format, making things quite complicated. The
conditionals depend on outside knowledge (eg. exact chip names, Xtensa TRAX
register bases, ...) which I don't have, so those are currently left ignored.
## License
Eh, idk yet.