Even More Firmware in your Firmware

Even More Firmware in your Firmware

There are many ways to update an embedded system in the field. Images can fly through the air one a time, travel by sneaker or hitch a ride on other passing data. OK, maybe that’s a stretch, but there are certainly a plethora of ways to get those sweet update bytes into a target system. How are those bytes assembled, and what are the tools that do the assembly? This is the problem I needed to solve.


Recall, my system wasn’t a particularly novel one (see the block diagram below). Just a few computers asking each other for an update over some serial busses. I had chosen to bundle the payload firmware images into the binary for the intermediate microcontroller which was to carry out the update process. The additional constraint was that the blending of the three firmware images (one carrier and two payload) needed to happen long after compile time, on a different system with a separate toolchain. There were ultimately two options that fit the bill.


The system thirsty for an update

There’s more than one way to use the linker to stick binaries together — that’s its job after all. A typical compilation toolchain uses ld to string object files together, but there are other linker-adjacent tools which come in handy for playing havoc with the right kind of binary file. This method for bundling firmware images together will focus on a new tool in the GCC, objcopy.


To abuse the metaphor, objcopy is a bit of a utility knife for object file manipulation. The breadth of it’s functionally is wide but the specific thing we need here is the --update-section parameter, which allows us to replace a named section ..

Support the originator by clicking the read the rest link below.