more stuff in the README
This commit is contained in:
parent
f05fe9d9d5
commit
1df064852c
51
README.md
51
README.md
|
@ -23,3 +23,54 @@ MMIO register definition files.
|
||||||
* DSLite → SVD [*planned*]
|
* DSLite → SVD [*planned*]
|
||||||
* SVD → DTS/DTB (peripherals only) [*planned*]
|
* SVD → DTS/DTB (peripherals only) [*planned*]
|
||||||
* DTS/DTB → SVD (peripherals only) [*planned*]
|
* DTS/DTB → SVD (peripherals only) [*planned*]
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
#### Libraries
|
||||||
|
|
||||||
|
* `dvf/dvfparse.py` is able to parse DVF files
|
||||||
|
* `svd/svd.py`, `svd/svdparse.py`, `svd/svdgen.py` handle SVD files
|
||||||
|
|
||||||
|
#### Utilities
|
||||||
|
|
||||||
|
* `dvf/dvf2h.py` is a quick DVF-to-headerfile converter
|
||||||
|
* `dvf2svd.py` 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
|
||||||
|
ways.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
Loading…
Reference in New Issue