Beyond the Demo Kernel: Mapping BSPs to Mainline
summary
Shows a practical method to shrink a vendor BSP to the real upstream delta: use code fingerprinting and fuzzy matching on source and history, run artifact drift analysis (modules, DTBs, objects) and symbol-level checks to see what actually loads, and run repeated out-of-tree builds and CI to triage failures. Prioritize landing clocks/reset/power/bindings first, subtract identical upstream content via git metadata, and produce small, dependency-ordered patch series so integration is reviewable and sustainable.
AI-written summary · about
chapters (16)
- 0:00Introduction to BSP mapping
- 1:01What a BSP really is
- 3:39Device tree bindings and lineage
- 8:46Tracing active drivers in BSP
- 11:40Identifying genuine hardware support
- 15:45Analyzing exported symbols
- 17:52Subtracting mainline from BSP
- 19:24From archaeology to building
- 20:09Upstreaming strategy and order
- 23:01Out-of-tree build failures
- 24:26Detecting upstream lineage
- 25:32Consolidating BSP drivers
- 27:02Divergence from LTS and mainline
- 28:03Keeping BSP stable during upstream
- 30:13Treating BSP as bootstrap
- 31:19Q&A session
related talks
50mRethinking U-Boot Devicetree Story
47mUpstream LTS Component for Product Delivery
29mBehind the Curtains of Making Real Consumer Devices using Debian
49mCode Review Training for Kernel Patch Reviewers
55mThe Embedded Linux Problem
41mBoot-Time BOF
44mBoF: Devicetree
24mLessons Learned Migrating to Modern Multi-Platform eBPF Programs