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*]
|
||||
* SVD → DTS/DTB (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