Second Source Component Probing on Device Tree Platforms
summary
ChromeOS ARM work that tests concrete fixes rather than theory shows three practical approaches: in-kernel probing on I2C busses that sequentially powers and probes disabled DT nodes, device node activation based on firmware provided properties when an identifier exists, and FIT image overlay selection for merging skews into a base DTB. Patches are on the mailing list, claimed savings around 6.7% DTB size for one conversion, and unresolved pain points remain for address conflicts and hard‑to‑probe panels and cameras.
AI-written summary · about
chapters (21)
- 0:00Second source probing intro
- 1:09What is second sourcing
- 2:34Device tree basics
- 4:03ChromeOS bootloader FIT
- 6:39Challenges with multiple DTs
- 7:01Design impact on DTs
- 8:45I2C address conflicts
- 11:41Probing non-conflicting I2C
- 13:28Synchronous probing conflicts
- 15:37Firmware vs kernel probing
- 17:30Device driver for probing
- 18:59Hardware IDs for probing
- 20:30Merging SKUs into DT
- 21:35Per-variant overlays
- 23:02MT8186 Corsola case study
- 24:29DTSI to DTS overlays
- 26:41Two-layer overlays
- 28:49Per-component overlays
- 30:40FIT overlays extension
- 32:05Solutions and trade-offs
- 32:50Q&A
related talks
40mSecond Source Component Probing on Device Tree Platforms
44mSolving Devicetree Issues, part 3.0
01h 10mBoF: Devicetree
44mBoF: Devicetree
50mHotplug of Non-discoverable Hardware: Status and Future Directions
55mImplementing State-of-the-Art U-Boot Port, 2018 Edition
29mChallenges in Device Tree Sync - kernel, Zephyr, U-boot, System DT
32mBuilding a Debug Probe with the Zephyr RTOS