If you’ve started working on an embedded software project, you’ve probably reached the point where you looked around for an update system, and found out that there isn’t a lot of great tooling out there. Our experience has been that people tend implement software updates on a case-by-case basis, leading to solutions that are specific to the target platform, proprietary, brittle, or insecure—​or sometimes all of the above. ATS Garage provides an open source solution that you can plug-and-play into your build process.

Let’s look at the parts of the system, and how they fit together.


The Yocto Project is an open source collaborative project that provides standardized high-quality infrastructure, tools, and methodology to help decrease the complexity and increase the portability of Linux implementations in the embedded industry. It enables its users to build custom operating systems using specific recipes for embedded devices. Most commercial embedded Linux distros already use and/or support Yocto, including Wind River and Enea. It’s backed by major hardware vendors like Intel, AMD, Freescale, Mentor, Texas Instruments, and many others. If you need a highly performant customized Linux for your embedded device, whether it’s IoT, automotive, or other kinds of mobility devices, the Yocto project is probably what you’re using.

HERE Technologies has created a meta-updater layer for Yocto, making it easy to get over-the-air update support into your devices. In many cases, it’s as simple as adding meta-updater and a board support integration layer to your project and re-running bitbake. The main feature of the meta-updater layer is OSTree.


OSTree is an open-source tool that combines a "git-like" model for committing and downloading bootable filesystem trees, along with a layer for deploying them and managing the bootloader configuration. It is actively developed and support by Red Hat, and used in flatpak and Project Atomic.

For more on why OSTree is the best tool for the job of doing embedded device updates, take a look at Comparing full-filesystem update strategies.

Doing It Wrong™: Bad choices for embedded updates
  • Package managers

    Hey, every Linux distro does it this way—​why don’t I use it for my embedded system? The problem with this approach is that updates aren’t atomic, so it’s quite easy to get the system into a state that requires user intervention to fix, especially if it’s rebooted during an update. That might be fine on the desktop or on a server, but it doesn’t work for embedded devices.

  • "Update Mode" and similar designs

    Fortunately, we rarely see this design in the wild anymore. When we do, it’s typically a legacy of days when microcontroller flashing would be done in person, with a new image streamed over a serial interface to overwrite the old system. This is a very poor choice for embedded, because it’s extremely common for users to disconnect the device while the new image is being flashed, potentially bricking the device or requiring a more difficult intervention to fix. Lower-end home routers and DSL modems sometimes go this route; doing a quick Google search for "firmware update bricked router" should show why this is a bad idea.


Since OSTree is "git-like", you can probably imagine that you can have remote repositories. TreeHub is exactly that. It’s seamlessly integrated into the meta-updater layer and into the ATS Garage site itself. Your builds get automatically pushed to TreeHub as soon as you make them, and you can use ATS Garage to wirelessly update your devices—​one at a time, or in targeted campaigns. You can even set devices to automatically pull updates from TreeHub as soon as they’re pushed, and stop wasting time re-flashing the units on your test bench every time you build new code.