Zephyr Extensions: How to Dynamically Load an Application
summary
Demonstrates a Zephyr extension workflow that loads ELF modules from the filesystem at boot, exports and resolves symbols between base firmware and extensions, and runs a runtime-loaded counter plugin plus a full CANopen stack on an STM32 Cortex-M4. Build changes add missing ARM relocations, a simple config file and syscall/callback hooks, and patches upstreamed to Zephyr. Performance matches built-in code (simulink curves overlap), load times measured about 10 ms for a tiny counter and 160 ms load for the CANopen extension, with open questions on cybersecurity and safety certification.
AI-written summary · about
chapters (15)
- 0:00Industrial context
- 3:56State of the art solutions
- 6:45Zephyr's LLT subsystem
- 8:51Enhancing LLT for use
- 11:44File system integration
- 13:32Proof of concept counter CANopen
- 16:26Performance analysis impact
- 19:40Dynamic loading benefits drawbacks
- 21:04Cybersecurity safety concerns
- 22:53Sharing code back to the Zephyr community
- 26:50Open-source collaboration
- 27:34First contribution
- 29:46Demo setup
- 31:46Dynamic loading demo
- 32:29Q&A
related talks
39mZephyr Extensions: How to Dynamically Load an Application
39mExtending Zephyr Based Applications at Runtime with LLEXT
27mZephyr and Trusted Execution Environments
27mZephyr and Trusted Execution Environments
15mExtending Applications Safely and Efficiently
32mFuzzing Zephyr Apps - Struggles of Dynamic Analysis on Embedded Applications
31mHow to Integrate My (Proprietary) Code in Zephyr
31mUsing Zephyr for Embedded Controllers