From 1df064852cd42539c3cb71439bc57fa64d615c1e Mon Sep 17 00:00:00 2001 From: Triss Date: Wed, 1 Jun 2022 17:15:58 +0200 Subject: [PATCH] more stuff in the README --- README.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/README.md b/README.md index 5086c44..3a3b53e 100644 --- a/README.md +++ b/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.