Stable Devicetree ABI: it's possible!
summary
Claims that a stable Devicetree ABI is possible and reproducible using concrete rules and platform workarounds. Pengutronix work on NXP i.MX6 shows practices: define exhaustive required properties, use new compatible strings for new silicon, infer properties from hardware rather than forcing DT fields, prefer kernel-side fixes before changing bindings, and add a compatibility layer in drivers when a binding must break (example: SPI DMA quirk and power-domain rework). Result: newer kernels boot older DTs with reduced functionality and clear warnings.
AI-written summary · about
chapters (17)
- 0:00Intro
- 2:40Why should we care
- 4:10Interactions between bootloader and kernel
- 6:33Stable API
- 10:58Hardware Bindings
- 14:23Things weve learned
- 15:53Calling names
- 16:24Comfortable
- 17:07Bare examples
- 18:02Always use new drivers
- 18:26Using new drivers
- 19:20Fixing the devicetree
- 21:20Breaking a binding
- 25:30Probe function
- 26:45Conclusion
- 27:46Summary
- 29:02Questions
related talks
50mRethinking U-Boot Devicetree Story
51mShipping Multiple Devicetrees: How to Identify Which DTB Is for My Board?
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
15mIs the Zephyr Device Tree Too Complicated?
11mBuilding a Test for Diverse Fleet of Platforms, How Hard That Could Be?
37mHow to Get Your DT Schema Bindings Accepted in Less than 10 Iterations
43mReproducible Multi Element System Composition with Linux, Xen & Zephyr
41mFuture of Zephyr Device Model