Run-Time Dynamic Linking for Reprogramming Wireless Sensor Networks

1. Adam Dunkels, Niclas Finne, Joakim Eriksson, Thiemo Voigt Swedish Institute of Computer Science ACM SenSys 2006 Run-Time Dynamic Linking for Reprogramming Wireless SensorNetworks

2. The setting: software updates in sensor networks We are here Operating system with loadable native code modules

3. We all have our own way of doing loadable modules • Contiki [EmNetS 2004] • Statically linked modules, relocation at run-time • SOS [MobiSys 2005] • Modules with position independent code • Why not just do it the standard “Linux” way? • Run-time linking of ELF files • Availability of tools, knowledge • Are we compelled to do it our own way? • Or do we choose to do it our own way? • Can we even do it the “Linux” way in microsensor networks? • Given the severe resource constraints: 2k RAM, 60k ROM • If we could, what would the overhead be?

4. What we’ve done • Developed a dynamic linker for Contiki • Link, relocate, load standard ELF files • CVM (Contiki VM) – a virtual machine • Typical, stack-based virtual machine • Compiler for a subset of Java • Java virtual machine • Ported the leJOS Java VM to Contiki

5. Conclusions • Proof of concept: dynamic linking of ELF files is possible and feasible for sensor networks • Code size < 2k, memory size < 100 bytes • Acceptable transmission overhead (ELF size factor 3) • Communication is by far the dominating factor • Energy consumption for the dynamic linking is low • Depending on the scenario, combinations may be the most efficient • Virtual machine code with dynamically loaded native libraries

6. The details…

7. Reprogramming methods • Virtual machines, script languages • Native code • Full image replacement • The default method for many embedded systems, TinyOS • Delta/diff-based approaches • Compare two versions of the compiled code, transmit only the changes • Need to know both versions • Loadable modules • Requires support from operating system

8. Loadable modules ROM RAM Loadable module RAM Loadable module System core System core

9. while(1) { send(); } Linking, relocation, loading ROM Loading Linking Relocation RAM 0x2300 jmp 0x2300 void send() { /* … */ } 0x164b 0x0000 call 0x164b call 0x0000 Loadable module jmp 0x0000 System core

10. Linking, relocation, loading ROM Loading 0x2300 call 0x164b Loadable module jmp 0x2300 void send() { /* … */ } 0x164b System core

11. Static pre-linking, position independent code ROM • Static pre-linking • Do all linking at compile time • Must know all core addresses at compile time • All nodes must be exactly the same • Configuration management nightmare • Contiki [EmNetS 2004] • Position-independent code • No need for relocation • Only works on certain CPU architectures • Limitations on module size • SOS [Mobisys 2005] 0x2300 call 0x164b Loadable module jmp 0x2300 void send() { /* … */ } 0x164b System core

12. Dynamic linking needs meta-data ROM • Addresses of all locations that needs to be patched • The names of called functions and accessed variables • Symbol table in core • ELF – Executable Linkable Format • Contains code, data, relocation/linking information, referenced symbols • Standard format for Linux, Solaris, FreeBSD, … • The output format from gcc (.o files) • Many tools available 0x2300 call 0x164b Loadable module jmp 0x2300 void send() { /* … */ } 0x164b System core

13. “ELF16” • The obvious problem with ELF files: • ELF (ELF32) uses 32-bit structures • Lots of “air” in an ELF file for a 16-bit CPU • The obvious optimization: • “ELF16” – (Compact ELF) like ELF but with 16-bit structures • The dynamic loader works with both ELF32 and “ELF16” file – only the structure definitions are different

14. The virtual machines • CVM – Contiki VM • A stack-based, typical virtual machine • A compiler for a subset of Java • The leJOS Java VM • Adapted to run in ROM • Executes Java byte code • Bundled .class files

15. So how well does it work?

16. Memory footprint • ROM size of dynamic linker • ~ 2k code • ~ 4k symbol table • Full Contiki system, automatically generated • Dynamic linking feasible for memory-constrained systems • But CVM is better

17. Quantifying the energy consumption • Measure the energy consumption: • Radio reception, measured on CC2420, TR1001 • A lower bound, based on average Deluge overhead • Storing data to EEPROM • Linking, relocating object code • Loading code into flash ROM • Executing the code • Two boards: ESB, Telos Sky (both MSP430)

18. Receiving 1000 bytes with the CC2420

19. Receiving 1000 bytes with the TR1001

20. Energy consumption of the dynamic linker

21. Loading, linking native code vs virtual machine code Object tracking application

22. ELF file size Average ELF overhead 3, average “ELF16” overhead 1

23. Running native code vs virtual machine code • 8x8 vector convolution • Computationally “heavy” • Object tracking application • Uses native code library • Most of the code is spent running native code

24. Break even points, vector convolution “ELF16”

25. Break-even points, object tracking “ELF16”

26. Conclusions • Dynamic loading of native code in standard ELF files is feasible in sensor networks • The overhead lies in the transmission, not the linking • Code size ~2k, memory size < 100 bytes • ELF format has ~ 300% overhead • (“ELF16” has ~ 100% overhead) • Sometimes other factors outweigh the energy overhead • Availability of tools • Dynamically linked native code vs virtual machines • Combinations: virtual machine code with dynamically linked native code

27. Questions?

28. Full image replacement • Blinker application • Module 150 bytes • ELF file 1k • Full system 20k • 2000% energy overhead

29. Portability of the dynamic linker • Dynamic linker consists of two parts • Generic ELF code • Architecture specific relocation and loading code

30. Scenarios for software updates • Software development for sensor networks • Small updates, often, at any level, programs short-lived • Sensor network test-beds • Large updates, seldom, at the application level, programs long-lived • Fixing bugs • Small updates, seldom, at any level, programs long-lived • Application reconfiguration • Very small updates, seldom, at the application level, programs long-lived • Dynamic applications • Small updates, often, at the application level, programs long-lived