RFC: refactor devicetree (DTS) generation (draft)

[AndrewD]

Current status

The current state of litex_json2dts_linux.py is just enough to generate a DTS for {linux_on_litex_vexriscv,rocket} with some of the standard devices, however it is hardcoded to just the standard litex peripherals with linux drivers and does not cater for other litex cores in separate git modules or custom peripherals. Some devices are only partially supported with mostly hard coded configuration, eg custom instances of gpio for leds and pwm for rgb_led.

Motivation

To generalise the dts to cater for standard peripherals in a generic way and also support additional peripherals.

Proposal

• Move some generic dts functions from litex.tools.litex_json2dts_zephyr into a common json2dts module: maybe litex.tools.json2dts
• add dts helpers get_csr_regions_of() get_mem_regions_of() to extract regions from csr_bases (csr_base size by parsing car_registers) and memories.
• maybe move the generic dts functions into a JSON2DTS class
• improve handling of levels for indentation to support the linux dts
• start to use generic dts functions in litex.tools.litex_json2dts_linux
• add of related metadata to the soc
  1. use soc.add_constant() to inject constants with a prefix of "{name}of" to provide some required dts information, for example soc.add_constant(name + "_of_compatible", "litex,timer") (prototyped), OR
  2. add a dts specific dictionary to the soc and write this into csr.json. Some dts names such as #gpio-cells don't suit also being generated into c #defines
• fix linux dts schema validation warnings, eg Generated DTS lacks root compatible and model properties #1905
• fix inconsistencies between soc and device tree, eg sdcard_block2mem in soc translated to reader in dts
  1. be consistent: use either block2mem or reader in both soc and dts, or
  2, add an optional alias attribute for csr_regions and mem_regions that can be supplied by the soc.

Status

I have some work in progress that implements the checked items above (using soc.add_constant) and can generate device tree entries for simple peripherals.

TODO

• DRAFT PR for discussion

[m-byte]

It's pretty much the same for the zephyr version of this script. I believe it would be preferable, if these two scripts could be combined as it should be possible to have only minor differences between Zephyr and Linux dts files for LiteX.

As for custom peripherals from separate git repos, being able to support them with the same script would be even better. As it stands, we currently have our own hard coded copy of the zephyr script that we are working with. That's probably what most do, but it makes collaboration harder and (unnecessarily) raises the entry barrier.

[m-byte]

@maass-hamburg

[AndrewD]

Description edited, more to do

[AndrewD]

@enjoy-digital @trabucayre this issue describes the motivation behind the changes in #1975. This is a minimal change to start dynamically generating dts content for litex cores/modules instead of hard coding in the json2dts scripts.
With these changes we have been able to remove all of our local customisations from litex_json2dts_linux.py.

In the future a pure python dts library like https://github.com/molejar/pyFDT may be interesting to consider as a more fully featured approach if DTS generation is moved into Builder.