<commit_before>[![Build Status](https://travis-ci.org/mendersoftware/mender.svg?branch=master)](https://travis-ci.org/mendersoftware/mender)
[![Coverage Status](https://coveralls.io/repos/github/mendersoftware/mender/badge.svg?branch=master)](https://coveralls.io/github/mendersoftware/mender?branch=master)

# Mender 

Mender is a framework for automating over-the-air software updates to Linux-based embedded devices.

In order to test it, it is strongly recommended to build it as a part of a Yocto image,
as you will need to have the bootloader and partition layout set up in a specific way.
Yocto layers are provided in the [meta-mender](https://www.github.com/mendersoftware/meta-mender)
repository.

1. How it works
===============

Mender performs a full image update of the embedded device. Currently, both the kernel and rootfs
are expected to be part of the image update. Updating the bootloader is considered less important and more
risky, so the first version of Mender is not designed to update the bootloader.


2. Partitioning target device
=============================

At least three different partitions are required, one of which is the boot partition, and the
remaining two partitions are where both the kernel and rootfs are stored. One of the partitions will be used
as active partition, from which the kernel and rootfs will be booted, the second one will be used by the update mechanism to write the updated image. The second partition will be referred to as "inactive" later in this document.

It is also possible to use yet another partition to store persistent user data, so this does not
get overwritten during an update.

A sample partition layout is shown below:

```
           +--------+
           | EEPROM |
           +--------+
     +----------------------+
     | boot partition (FAT) |
     +----------------------+
    +-----------+-----------+
    | rootfs    |  rootfs   |
    | kernel    |  kernel   |
    +-----------+-----------+
          +------------+
          | user data  |
          | (optional) |
          +------------+
```

3. Bootloader support
=====================

Mender is currently designed to be used with the U-Boot bootloader. The choice of U-Boot was made based on
its flexibility and popularity in embedded devices. It is also open source, which enables any required
modifications or adjustments.

Besides any special configuration to support the device, U-Boot needs to be compiled and used with a feature known as
as [Boot Count Limit](http://www.denx.de/wiki/view/DULG/UBootBootCountLimit). It enables specific actions to be triggered
when the boot process fails a certain amount of attempts.

Support for modifying U-Boot variables from userspace is also required so that fw_printenv/fw_setenv utilities
are available in userspace. These utilities [can be compiled from U-Boot sources](http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux) and are part of U-Boot.



4. Boot process
===============

TBD



5. Testing Mender with Yocto and Qemu
=====================================

To quickly get started, Mender can be tested using the qemu emulator.
Detailed instructions how to build a Yocto image that can be run and tested in qemu are provided in the
[meta-mender-qemu repository ](https://www.github.com/mendersoftware/meta-mender-qemu).

<commit_msg>replace meta-mender-qemu with meta-mender<commit_after>[![Build Status](https://travis-ci.org/mendersoftware/mender.svg?branch=master)](https://travis-ci.org/mendersoftware/mender)
[![Coverage Status](https://coveralls.io/repos/github/mendersoftware/mender/badge.svg?branch=master)](https://coveralls.io/github/mendersoftware/mender?branch=master)

# Mender 

Mender is a framework for automating over-the-air software updates to Linux-based embedded devices.

In order to test it, it is strongly recommended to build it as a part of a Yocto image,
as you will need to have the bootloader and partition layout set up in a specific way.
Yocto layers are provided in the [meta-mender](https://www.github.com/mendersoftware/meta-mender)
repository.

1. How it works
===============

Mender performs a full image update of the embedded device. Currently, both the kernel and rootfs
are expected to be part of the image update. Updating the bootloader is considered less important and more
risky, so the first version of Mender is not designed to update the bootloader.


2. Partitioning target device
=============================

At least three different partitions are required, one of which is the boot partition, and the
remaining two partitions are where both the kernel and rootfs are stored. One of the partitions will be used
as active partition, from which the kernel and rootfs will be booted, the second one will be used by the update mechanism to write the updated image. The second partition will be referred to as "inactive" later in this document.

It is also possible to use yet another partition to store persistent user data, so this does not
get overwritten during an update.

A sample partition layout is shown below:

```
           +--------+
           | EEPROM |
           +--------+
     +----------------------+
     | boot partition (FAT) |
     +----------------------+
    +-----------+-----------+
    | rootfs    |  rootfs   |
    | kernel    |  kernel   |
    +-----------+-----------+
          +------------+
          | user data  |
          | (optional) |
          +------------+
```

3. Bootloader support
=====================

Mender is currently designed to be used with the U-Boot bootloader. The choice of U-Boot was made based on
its flexibility and popularity in embedded devices. It is also open source, which enables any required
modifications or adjustments.

Besides any special configuration to support the device, U-Boot needs to be compiled and used with a feature known as
as [Boot Count Limit](http://www.denx.de/wiki/view/DULG/UBootBootCountLimit). It enables specific actions to be triggered
when the boot process fails a certain amount of attempts.

Support for modifying U-Boot variables from userspace is also required so that fw_printenv/fw_setenv utilities
are available in userspace. These utilities [can be compiled from U-Boot sources](http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux) and are part of U-Boot.



4. Boot process
===============

TBD



5. Testing Mender with Yocto and Qemu
=====================================

To quickly get started, Mender can be tested using the qemu emulator.
Detailed instructions how to build a Yocto image that can be run and tested in qemu are provided in the
[meta-mender repository](https://www.github.com/mendersoftware/meta-mender).


{'fraction_non_alphanumeric': 0.13377876763177432, 'fraction_numerical': 0.0014847809948032665, 'mean_word_length': 3.2579013906447534, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 12, 'lorem ipsum': 0, 'www.': 8, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1806825', 'n_tokens_mistral': 1798, 'n_tokens_neox': 1713, 'n_words': 788}