DTS target integration #1975
DTS target integration #1975
Conversation
|
Thanks @AndrewD, I'll have to think about the global approach for this. We also have been thinking with @trabucayre about switching to a python lib ease generation of the dts files, which could also help here. |
|
Hi @enjoy-digital, Ultimately I needed very little that is DTS specific and most was already in json2dit_zephyr so it seemed easiest to follow the pattern and leverage that. |
AndrewD
force-pushed
the
dts_target_integration
branch
from
0390945
to
70b7aed
Compare
|
@enjoy-digital I've removed the python 3.10 dependency. I did notice that the litex:setup.py specifies python >= 3.7 but the CI build is with 3.9? |
|
Thanks @AndrewD, I'll have a closer look at the changes but haven't had the time to think more about it yet (In the past, I merged some features in the project because I was not able to closely review things and to avoid frustrating developers, but this also created lots of headaches for me later to undo some things or do things differently to allow the project to go further). For this change, I first prefer that we have a clear vision of the direction before we start doing changes. I would first like to rework the way .dts files are generated (with helper code or a python lib), then think about the mechanism to collect information and generate the .dts information to the .json file and then how to reuse this information to generate the .dts dynamically. If we apply this approach to the peripherals, we should also probably apply it to the CPUs. Let me think about this, discuss with @trabucayre internally and we'll get back to you. |
AndrewD
force-pushed
the
dts_target_integration
branch
from
70b7aed
to
eb0358e
Compare
AndrewD
force-pushed
the
dts_target_integration
branch
from
eb0358e
to
f989254
Compare
|
@enjoy-digital we are actively using this and have made further refinements for our own usage. I've pushed an update of the current state that has been squashed down to a few commits (without the initial experiments). Do you have any further thoughts yet? While the impact on Litex is isolated this is now quite solid and could replace most of the hard coded nodes for modules in json2dts_linux: json2dts_zephyr could also leverage this. |
|
Thanks @AndrewD. We haven't yet been able to fully think about the right approach (busy with other things and other tasks we are working on together). We'll definitly spend more time on this in September and will find a solution that will satisfy both of us. Sorry for being slow on this. |
To support linux dts generation.
addr size pairs should be enclosed '< >' and comma separated to be dts compliant.
some dts related constants are invalid names for the c preprocessor, so need to be excluded from code generation.
Example usage in modules to follow
add_timer() will now generate a dts entry.
spi_mmap will require target integration, for example:
self.spi_mmap_1 = SPIMMAP(...)
self.add_dts_node("spi_mmap_1", self.spi_mmap_1)
gpio will require target integration, for example:
self.gpio = gpio = GPIOTristate(pads = pads)
self.add_dts_node("gpio", gpio)
NOTE: GPIOIn and GPIOOut will generate DTS compatible with the current
Linux driver, but the existing DTS nodes for litex GPIO depart from
DTS conventions are are worth changing if there are no compatibility
concerns.
Will require target integration
AndrewD
force-pushed
the
dts_target_integration
branch
from
f989254
to
715098f
Compare
This set of changes follows on from #1972, #1973, #1974 and adds a mechanism to specify DTS information for a core from anywhere within litex.
With these changes we can generate a valid DTS for standard litex cores and custom cores without needing to hard code any support into litex_json2dts_linux.py and implements most of the concepts detailed in #1960.
@enjoy-digital any feedback on style or details would be appreciated.