search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.82k stars 6.59k forks source link

Support parsing device tree runtime #32649

Open MrVan opened 3 years ago

MrVan commented 3 years ago

The current Zephyr driver use compiling time device tree info. To make it flexible, I am thinking the support for runtime parsing device tree for aarch64 which is more powerful. And this will make life easier when porting drivers to Zephyr.

@carlocaione @sandeepbrcm @jharris-intel

carlocaione commented 3 years ago

having that it would be great and I'm totally for it. But being a huge change for Zephyr I think that needs to be discussed. So I'm tagging a few people that can have something to say about this. @pabigot @nashif @ioannisg @mbolivar-nordic @galak

galak commented 3 years ago

I don't think this makes sense in general as the reason we generate code/defines from devicetree is size / footprint for the majority of systems that utilize Zephyr.

So having a DTB and the associated code to parse it at runtime is overhead that isn't acceptable for those systems.

As we need to maintain support for a non-runtime devicetree usage, not sure what supporting runtime devicetree would get us?

pabigot commented 3 years ago

This could be useful for more complex applications. Once we start supporting devices that are left off on startup, and only turned on by the application, a natural extension is to support that with runtime configuration of available devices ("DT overlays" the way Linux supports them through an API).

Using DTB for describing those devices makes more sense than coming up with a home-grown solution.

carlocaione commented 3 years ago

So having a DTB and the associated code to parse it at runtime is overhead that isn't acceptable for those systems.

Agree, but nothing prevents us to have both the solutions in place right? For example having a small DT in-memory parsing library to link only when needed.

galak commented 3 years ago

Agree, but nothing prevents us to have both the solutions in place right? For example having a small DT in-memory parsing library to link only when needed.

Agreed, would like to see a proposal as to what that might look like. What the benefits would be, etc.

carlescufi commented 3 years ago

Agree, but nothing prevents us to have both the solutions in place right? For example having a small DT in-memory parsing library to link only when needed.

define "small" :) But yes, I do agree with the ability to do that as long as it's always opt-in. It's a bit like userspace support, which is a feature that makes little sense in the smallest devices but can be very useful on the more powerful ones.

jharris-intel commented 3 years ago

There's a few components here:

  1. Runtime devicetree parsing would add code size. (...and size to store the device tree.)
  2. Runtime devicetree parsing would add runtime complexity (read: more things to go wrong during boot / when debugging...)
  3. Runtime devicetree parsing would increase time-to-boot (due to the time to parse the device tree, among other things.)
  4. Runtime devicetree parsing would decrease runtime performance (somewhat, because info in the device tree can't be const-propagated.)

In exchange, you gain "easy" support for a family of related boards.

Note a few limitations (some surmountable):

  1. Runtime devicetree still doesn't help you across processor architectures.
  2. Runtime devicetree doesn't help you (much) with optional processor features.
  3. Runtime devicetree still requires that you have the drivers compiled in ahead of time.

All told? I understand why e.g. Linux does it; for the usecases I'm interested in, I doubt you'd use runtime devicetree support. It's way overkill for e.g. "hey, I want to change this one feature of this one driver across these two boards", or "hey, I want to only boot up the e.g. I2C driver if this board has something attached to I2C", and comes at a cost.

I don't have an issue with Zephyr adding optional runtime devicetree support, so long as the support is actually optional, and doesn't come at a cost of compile-time devicetree support. (Or, to elaborate on that a little. One "classic" failure mode of such things is the "old" feature rapidly becomes a second-class citizen because many things gratuitously rely on the New Shiny feature.)

(I am mildly concerned about tying post-boot driver configuration to runtime DTS, for instance.)

mbolivar-nordic commented 3 years ago

I think we all agree this could never be made mandatory even if it gets implemented.

I don't have any uses for runtime DT parsing personally and I would be quite concerned about potential extra complexity if we introduce it as an option. However, I'd be open to seeing how it works if someone has an RFC.

And this will make life easier when porting drivers to Zephyr.

If they are Linux drivers, you can't copy the code anyway for license reasons. I know some BSDs use DT as well but I'm honestly not convinced that this should be a goal. The zephyr device model is so different that I'm not sure I see how the DT conversion is really the hard part here.

zephyrbot commented 9 months ago

Hi @galak,

This issue, marked as an RFC, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@MrVan you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!