[FOTA] Tech key point: OSTree Deployment

The FOTA solution is designed for delivering firmware and/or disk images to automotive electronic control units (ECUs). But because we designed it with auto-industry robustness and security requirements in mind, it’s also a great way to deliver updates to any embedded Linux system.

In general, in a vehicle, we have dozens of individual ECUs, with varying capabilities. In a modern vehicle, that will usually include a small number of high-capability ECUs, including one with a connection to the internet. We call that one the Primary ECU, and all the others Secondary ECUs. For OTA software updates, it’s the job of the Primary to download and check updates for itself, and for all the other ECUs in the vehicle. The Secondaries get their updates from the Primary, along with metadata that allows them to check for themselves whether the update is valid.

There are two types of software images that you can upload to your personal software repository on FOTA backend repositories:

1. Image Types

1.1 Primary (Linux Based) images

When you build a disk image for your embedded device, you normally get a file, like a WIC or ISO file, that you can flash onto the device’s memory. When you add liking the tooling (via the meta-updater Yocto layer) to your build process, you will also automatically create an OSTree repository, add the full filesystem to the repository, and upload it automatically to the FOTA backend.

1.2 Secondary (non-Linux Based) images

The FOTA solution is also designed to enable secure updates to Secondary ECUs. This can, of course, include non-Linux systems, and even tiny microcontrollers with no operating system.

Even though this functionality was developed for delivering firmware to Secondary ECUs, you can use it to send other kinds of updates as well, even for a single device. For example, you might have a data partition, software packages, or apps that you want to send updates to independently from the base system. Or, you might want to create a virtual Secondary for testing and have it just drop the file you uploaded somewhere on the filesystem.

1.3 TreeHub and 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.

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. Your builds get automatically pushed to TreeHub as soon as you make them, and you can use the FOTA client update your devices—​one at a time, or in targeted campaigns. You can even set certain 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.

2. Yocto

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.

The HERE 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 features of the meta-updater layer are OSTree and our OTA update client, aktualizr. OSTree handles the filesystem versioning, and aktualizr communicates with the server, downloads updates, and cryptographically verifies them following the Uptane framework.

2.1 Yocto on TCU

Layerscape LDP is the industry standard of Linux enablement software for Layerscape family of processors. It provides all the necessary drivers, tools, and libraries required to enable all features of the Arm-based Layerscape processors. Refer to https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/layerscape-linux-distribution-poc:LAYERSCAPE-SDK

Although it’s easy to get started with our quickstart guides and Yocto layers, there are quite a lot of moving pieces under the hood. Here, we’re going to walk through what’s actually happening when you:

  • Provision a new device

  • Build a Yocto image that can do atomic full-filesystem updates with rollback

  • Build a new version of the image and push the update to OTA Connect

  • Send it to a client device for installation

2.1.1 Provisioning a new device

TODO

2.1.2 Building the image

Download Yocto layers according to repo manifest

To download all Yocto layers as per repo manifest using repo utility, perform these steps:

$: mkdir ~/bin$: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$: chmod a+x ~/bin/repo
$: export PATH=${PATH}:~/bin
$: mkdir yocto-sdk
$: cd yocto-sdk
$: repo init -u https://source.codeaurora.org/external/qoriq/qoriq-components/yocto-sdk -b
dunfell
$: repo sync --no-clone-bundle

最后更新于