Second Source Component Probing on Device Tree Platforms
summary
Device trees for ChromeOS ARM often explode into dozens of near‑identical files when vendors swap compatible parts; workarounds in drivers and DT layout are flaky. The solution set includes in-kernel I2C probing via a platform driver that walks disabled nodes, does power sequencing, enables the one that answers and hands it to the kernel, plus firmware FIT overlay selection or per‑component overlays in the bootloader. One measured merge shows about 6.6% DTB size savings; patches live on the mailing list.
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
29mChallenges in Device Tree Sync - kernel, Zephyr, U-boot, System DT
01h 10mBoF: Devicetree
46mDevice Tree in Zephyr Project
50mRethinking U-Boot Devicetree Story
01h 13mDevice Tree for Dummies!
44mBoF: Devicetree