mmiogrok

Collection of Python libraries to parse, generate and convert between several MMIO register definition files.

Parse and generate

• ARM CMSIS-SVD (ARM etc.)
• Device tree (source/binary, peripheral only, no registers) [planned]

Parse only

• NEC/Renesas DVF (78K, RL78, V830/RH830, RX)
• Lauterbach TRACE32 PER (misc) [work in progress]
• Atmel/Microchip ATDF/ATpack (AVR etc.) [planned]
• Texas Instruments DSLite (MSP430 etc.) [planned]

Convert

• DVF → SVD
• PER → SVD [work in progress]
• ATDF → SVD [planned]
• 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.