System Devicetree Support in Zephyr
summary
A concrete proposal: system devicetree extends the Devicetree spec to model multiple CPU clusters, per-cluster memory maps, execution domains, and peripheral assignments so a single file can be post-processed into separate standard devicetrees for each firmware image. Prototype tooling (lopper-based transformations) and a Zephyr demo boot on multiple AMP cores exist and reveal a few spec issues. Integration uses CIS build to spawn per-image Zephyr builds; work is paused for a job transition but is intended to continue.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:23Device Tree in Zephyr recap
- 2:46Scalability limits
- 5:16System Device Tree solution
- 6:38Core features
- 10:28Execution domains
- 12:55Single data structure views
- 15:00CIS build integration
- 16:44Specification improvements
- 17:47Implementation progress
- 18:49Next steps
- 21:25Q&A 1
- 28:40Q&A 2
- 31:37Q&A 3
- 35:29Q&A 4
- 37:22Q&A 5
related talks
46mDevice Tree in Zephyr Project
41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...
29mChallenges in Device Tree Sync - kernel, Zephyr, U-boot, System DT- 41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
27mZephyr and Trusted Execution Environments
33mZephyr Support for Heterogeneous SoCs
40mHow to extract a bare metal flavor of code out of Zephyr to use in RTOS?