Do not merge: DTC compiler in Python #4728
Conversation
…ile() Signed-off-by: Leandro Pereira <[email protected]>
When parsing pre-processed .dts files, some nodes appear twice in the file, causing some nodes to not appear in the parsed data. Update the nodes recursively. Signed-off-by: Leandro Pereira <[email protected]>
It was not being used by any script, and parse_node() was setting it to the `type` variable, which contains the type `type` from Python. Signed-off-by: Leandro Pereira <[email protected]>
DTS files may be preprocessed by the C preprocessor in order to build nodes selectively based on configuration. When CPP touches a file, it leaves some directives that may be used by a compiler for errors and such; just ignore these lines as we're not going to need them. Signed-off-by: Leandro Pereira <[email protected]>
Some files contain lines such as "chosen { };", which were not being
correctly parsed.
Signed-off-by: Leandro Pereira <[email protected]>
DTS syntax allows for the following:
some-node {
property-name;
}
And the devicetree.py was converting property-name to a boolean
property with value 1. In order to dump the DTS file, store
`{empty: True}` instead.
Signed-off-by: Leandro Pereira <[email protected]>
This script parses a .dts file preprocessed by a C preprocessor and dumps it as a .dts. It's simlar to what the dtc compiler does, but without requiring a host dtc binary (which might not be available on all platforms Zephyr supports). Signed-off-by: Leandro Pereira <[email protected]>
|
I too don't know much about DT. That said the code looks reasonable to me and I'm all for switching to Python for dtc. For advanced usage and checking we can always look later into getting a cross-platform dtc binary based on the upstream compiler. |
|
Hi, this is great, and good timing. I integrated it into CMake and tested 96b_nitrogen:samples/hello_world. I think this has produced a failing test case. See gist for the steps to reproduce, the log output, and the DTS source that provokes the bug. It fails at a DTS line like this: Perhaps arithmetic expression evaluation has not been implemented yet? |
| args.boot_cpu, args.include_path) | ||
|
|
||
| if __name__ == '__main__': | ||
| sys.exit(main()) |
There was a problem hiding this comment.
I haven't seen sys exit used here before.
I see that flatten doesn't return anything, so sys exist isn't doing anything is it?
There was a problem hiding this comment.
It returns None, which ends up being 0. I use this idiom as it's often easier to just return from main() (like any C program) rather than call sys.exit() in main() directly. Not a big deal in this case, though.
|
@lpereira : Perhaps Python's built in ast library could be used to evaluate the expressions. Something like this: SebastianBoe@c741978 flatten.py no longer crashes. But I am getting a new error further down the pipeline ... |
|
Fixed the second problem. Most tests seem to be passing now, but I haven't completed a full CI run yet. |
|
sanitycheck found some issues ... samples/basic/button$ echo $BOARD seems to be a good test |
|
@SebastianBoe Thanks for fixing those things -- frdm-k64f does not have these expressions. I'm not sure about the phandles, however; if the end result works fine, I'm OK with it. I did not look at what dtc actually does to assign phandles or create those paths, so maybe flatten.py could be improved. Maybe if someone that knows device tree better could take a look. In any case, I won't have much time to work on this before the 1.10 merge window closes; if you'd like to take the baton, as this overlaps with your work on improving build on Windows, please feel free to. |
|
Closing in favor of #5615 |
4 participants
DTS files are flattened by the dtc compiler, which is a host tool that is tricky to work on Windows without mingw or other similar environment. Since we have our own DTS parser anyway, write a tool to flatten it out and generate the same output.
I've tested the script only with the preprocessed DTS for a frdm-k64f (found in outdir/frdm-k64f/dts/arm), and it seems to be generating a file that seems sane compared to what dtc generates when targeting dts.
I don't know much about devicetree (for instance, a phandle property is being generated for every node, even though it's not exactly needed), so some review here would be welcomed.
This has not been hooked up to the build system yet.