Fixing the Watchdog: How Open Documentation Empowers Community-Driven Hardware Support
Talkat Open Source Summit Europe 2025 · on Wednesday, 2025-08-27· at 11:55· Elicium 2B (Elicium Level 1)·
summary
Open documentation lets a reader trace a failing watchdog from kernel to silicon, pin down that the input clock is running at ~19 MHz instead of the expected kHz, find interrupt ID 240 and test point TP315 on the board, change the device tree clock, enable the ESM signals and PMIC GPIO, and submit upstream patches. The team uses TRM pages, vendor Excel register maps, U-Boot/kernel drivers and a multimeter; after the fixes the board reliably reboots.
AI-written summary · about
chapters (13)
- 0:00Fixing watchdog support
- 1:06Documentation in hardware support
- 3:20Evaluating documentation quality
- 7:57TI J784S4 EVM docs
- 9:01Debugging watchdog failure
- 15:36Watchdog hardware in TRM
- 19:10Verifying watchdog reset
- 21:17Watchdog reset signal path
- 23:46Probing board signals
- 28:17Enabling PMIC reset
- 30:23Systematic debugging recap
- 33:08Hardware enablement factors
- 34:31Acknowledgments
related talks
32mHow (Not) to Get the Vendor Driver Merged Upstream
23mOur Company and the Open Source Community: A Journey from Anxiety to Collaboration
40mContributing to Zephyr vs (Linux and U-boot)
19mLinuxKI on POWER: The kernel Performance Toolkit Porting Experience and Challenges
40mWorking with the Community: A Timeline for Adding Support for a New Board in Zephyr
30mTransforming New Product Development with Open Hardware
33mUsing Open Source Software to Build an Industrial-grade Embedded Linux Platform...
30mFrom an OSS-Fuzz Report to LKML Patch Submission: A Hands-on Journey