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

DT support #35

Open
d3zd3z opened this issue Dec 2, 2024 · 2 comments
Open

DT support #35

d3zd3z opened this issue Dec 2, 2024 · 2 comments

Comments

@d3zd3z
Copy link
Collaborator

d3zd3z commented Dec 2, 2024

No description provided.

@d3zd3z d3zd3z converted this from a draft issue Dec 2, 2024
@rruuaanng
Copy link

Typically, we use macros in C to access nodes. The principle involves concatenating basic properties and retrieving constants from devicetree_generated.h. I believe we can start by extracting C macro constants from Rust.
(If possible, it can be assigned to me, although I am not familiar with rust. But I think I can try to accept it.)

@LuskeyNoah
Copy link

LuskeyNoah commented Jan 11, 2025

@d3zd3z How far are you thinking of taking this for the initial implementation/milestone?

For non-phandle properties, I think one could take a similar approach to the Kconfig stuff; e.g. use build.rs and a bunch of parsing logic to generate code for a struct (of structs) that roughly mirror the devicetree's structure.

However, not sure what you were thinking for

  1. phandles (self referential structs are always tough in rust)
  2. strong typing of the nodes (likely via parsing of the assorted binding yaml files?)
  3. struct device* access from rust

Let's brainstorm through these sometime soon!

edit: nevermind, I see you have already done a significant amount of implementation in #15 . Please let me know if there is anything I can help with there.

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

No branches or pull requests

3 participants