v01d commented on issue #1020: URL: https://github.com/apache/incubator-nuttx/issues/1020#issuecomment-626341167
Yes, I wrote the proposal after reading about how Zephyr manages this and how it differs from the Linux approach and see how this could be applied to NuttX. You can read about it here: https://docs.zephyrproject.org/latest/guides/dts/intro.html Actually, Zephyr fully uses the devicetree to generate a tree starting from the description of architectures and soc families down to the board level. You can see all DTS here: https://github.com/zephyrproject-rtos/zephyr/tree/master/dts If you go into arm/ directory, you have the different arm variants defined such as armv7, armv8, etc. Then for chip and minor variants you have another definition. Finally, under boards/, you can find DTS for each board, such as this one: https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/nucleo_l476rg/nucleo_l476rg.dts The driver model (defined here: https://docs.zephyrproject.org/latest/reference/drivers/index.html) connets to the device tree via generic macros (https://docs.zephyrproject.org/latest/reference/devicetree/index.html) which allow them to request the required parameters (ie, which port should this driver use to talk to the device?). As you see, the devicetree is used from the ground-up in zephyr, even at the arch level. In this document I focused on the use case for board definitions. Of course Zephyr does a lot of things and it has a high complexity system for this, but one can take ideas from the approach and see what would work here or not. That said, I'm no expert on this, I'm learning as a go, so it is good if others have better experience on this to give their opinion. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
