Beyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...
summary
Zephyr is extended for mass production by compiling a superset of drivers and using a 128-bit UFSC stored in EC flash to select the correct driver at boot, costing ~10–30 KB of flash. Device tree entries define bit offsets and selector pairs that the build generates into constant-time switch logic; unused devices use defer_init so only selected drivers run. A build-time Component Manifest JSON lets the host probe I2C via EC passthrough and generate the UFSC during factory provisioning.
AI-written summary · about
chapters (24)
- 0:00Runtime hardware dynamism challenge
- 2:10Google’s open source firmware in Chromebooks
- 3:32Mass production hardware variability
- 5:16Evolution of board identification
- 7:47Legacy magic number limitations
- 8:51Bit mask solution with SSFC limits
- 9:54Why device tree alone failed
- 11:17Superset of drivers for flexibility
- 12:02Unified Firmware Second Source Config
- 13:05UFSC schema in device tree
- 14:29Auto-generating UFSC fields
- 14:49Policy pattern for hardware features
- 16:15Driver routing with selector
- 17:18Compile-time fast routing
- 18:44Boot delays from missing I2C
- 20:34UFSC framework overview
- 21:58Jason on hardware discovery
- 23:24Component manifest from device tree
- 25:32Probing hardware via I2C pass-through
- 27:18Multi-device drivers with lookup
- 29:02Integrating manifest with UFSC
- 30:33Approach benefits and limits
- 31:59Three key takeaways
- 33:27Q&A
related talks
46mDevice Tree in Zephyr Project
23mA Dive into Zephyr Device Driver Model
38mSystem Devicetree Support in Zephyr
33mImproving System Configuration for Zephyr and Beyond
41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con
47mSponsored Session: Does Zephyr Scare the Bare Metal Embedded Developer World?
15mIs the Zephyr Device Tree Too Complicated?- 41mZephyr & Linux Devicetree, Similarities and Differences – Practical Guide To Boards, Shields and Con