Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: refactor devicetree (DTS) generation (draft) #1960

Open
5 of 9 tasks
AndrewD opened this issue May 21, 2024 · 4 comments
Open
5 of 9 tasks

RFC: refactor devicetree (DTS) generation (draft) #1960

AndrewD opened this issue May 21, 2024 · 4 comments

Comments

@AndrewD
Copy link
Collaborator

AndrewD commented May 21, 2024

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
Copy link
Contributor

m-byte commented May 23, 2024

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
Copy link
Contributor

m-byte commented May 23, 2024

@maass-hamburg

@AndrewD
Copy link
Collaborator Author

AndrewD commented May 27, 2024

Description edited, more to do

@AndrewD
Copy link
Collaborator Author

AndrewD commented Jun 4, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants