System Device Tree Meeting Notes 2023 - OpenAMP/open-amp GitHub Wiki
- Bruce Ashfield
- Lizhi Hou
- Marti Bolivar
- Max Zhen
- Nishanth Menon
- Sonal Santan
- Tanmay Shah
- Tomas Evensen
- Nathalie Chan King Choy
- Hari Nagalla
- Rob Herring
- Sergei Korneichuk
- Marti: Latest work & plans to use System DT in Zephyr + discussion
- Lizhi, Sonal, Rob: Patches for PCI devices
- Zephyr use case has helped to clarify the System DT spec a lot & contributed spec documentation
- For historic reasons, Zephyr is using custom tooling, but trying to implement what's in the spec as faithfully as possible.
- Marti's presentation could be a good one for a conference
- Enabling DT on PCI and other buses is an area that needs unified effort to make it upstream. Linux Plumbers could be a good place to present how PCI use case pipe cleaned & is a working example.
- Lizhi/Sonal to ping Frank about reviewing
- Lizhi to forward testing thread to Rob
- Sonal & Nathalie to sync offline about Linux Plumbers
- Zephyr and System DT
- Recording
- Passcode: @hsa0y1x
- Marti's slides
- p.6 Differences in how Zephyr works vs others that use DT
- Green files go into DT scripts
- Can't count on host compiler on dev workstation
- Have Python implementation of DT spec b/c Zephyr's glue language is Python
- Converted to #defines in headers
- So, DT disappears after build unless you manually save the info into some state
- DT worked for a while, but then hit scaling limits
- Multi-core AMP SoCs not well supported in current build system
- No longer 1 board with 1 microcontroller with 1 CPU
- Things got really complicated with Arm v8-M with TrustZone & it will only get worse
- Think System DT can help
- p.10 Light blue background is traditional sysbuild & rest of white background is where System DT comes in
- Want to make sure we don't disrupt existing use cases
- p.11
- Will be using custom tools system instead of Lopper initially, but still intend to match the spec
- p.13
- So contributed documentation so that the spec was really clear, so know what to implement - that everyone agrees on
- p.14
- Have been discussing system DT spec tagging on lopper mailing list
- Zephyr & microcontroller world brings some new use cases to lopper, which could help improve System DT spec in 2.0
- Bruce: We're more than pleased to have worked on this use case & clean up & simplification of the spec. Good improvements. This is a second & very different use case, so good for making things general purpose. Looking forward to the next set of feedback from Marti. Suggest that Marti submit this talk to a conference.
- Tomas:
- AMD Xilinx baremetal drivers also using Lopper for RTOS. Great to see this use case.
- When do you think it is time to start tagging Lopper as well?
- Bruce: Soon. Lopper has date-based tags in pypi. Just added JSON support. Think 1.3 or 1.4 release will be next, but hadn't done a GitHub release yet. With cleanup to the docs, can have PDFs & release artifacts.
- Rob: How are you validating System DT part & Zephyr part?
- Marti: Zephyr has test suite in pytest. Feed in test DTs into DTC to make sure our tools match DTC output. Validating System DT will have to be similar. Want to start opening issues for to nail down semantics so that we can agree upon & develop a similar test suite.
- Rob: DTC has some checks, but very little. Anything device-specific is not checked.
- Marti: We do have our own bindings language in Zephyr (historic). Think would like to eventually move to DT schema, but is a big lift. Today we implement what's in the spec as faithfully as we can.
- Patch set for enabling DT on PCIe-based platforms
- Sonal: What would be next steps that Rob advises to take it forward?
- Rob:
- Frank wanted to review & haven't seen that happen. Suggest to ping Frank.
- Want to be able to test some of this out & haven't had chance to do that. Don't have a setup. If had a setup that was tied into DT unit test, that would help.
- There's another patch series doing similar things (added Sonal & Lizhi to it) - running device test on user mode Linux & adding devices under PCI w/ DT
- If Sonal's team could create a test setup could be faster.
- Lizhi: Did some test & posted test output in one of replies on list. Used our setup to create device & show how the address translation is correct. Lizhi will forward the test thread to Rob to review.
- Lizhi: Frank seems to be worried about fragility of overlay. Not sure how to resolve the concern - patch or fix to overlay itself? Does that have to be addressed before our patch can be accepted?
- Rob: Have to define the constraints under which the overlay is used & if the constraints avoid known issues, then it should be fine.
- Lizhi: First step doesn't even involve overlay. It creates the DT node, nothing using overlay yet. That would be the next step.
- Sonal: So, when we go to next step, then we would have to draw the boundaries that Rob mentions, to show we don't get into any minefields.
- Sonal: Followed email thread w/ Greg on this topic. Does Rob think that this is fine with Greg now?
- Rob: Yes, think it's fine w/ him.
- Sonal: Would this be a good tech topic to present at Linux Plumbers?
- Rob: Yes. Part of the problem is multiple ppl want the same thing, not just PCI, also USB. All the separate efforts won't get upstream, will need collaboration among the different use cases to make sure we get something that works for everyone. There is usually a PCI track at Plumbers. But, it's not just a PCI issue.
- Sonal: This is a general tech that could be supported for all kinds of buses & PCI is pipe cleaning & proving the concept
- Rob: That's 1 approach. The other use case w/ user mode Linux is purely for testing is also using PCI.
- Sonal: We can probably collaborate with them as well.