How to do a proxy deployment to an FRDM-K64F device connected to a Raspberry Pi 3

Introduction

When designing products based on Linux, it is a common design pattern to have external MCU that handles real-time critical tasks. The external MCU could be mounted on the same PCB as the Linux SoC, or it could be an external component that is connected to the Linux capable device, e.g over USB or a serial line.

The external MCU obviously then is another software component in the system that should be possible to update over the lifetime of the product.

In this tutorial we will walk you through how to use Mender to manage software updates for the external MCU utilizing the Linux capable device as an “proxy” as it will be the one running the Mender client.

In our setup we will be using a FRDM-K64F board as the external MCU which has support updating firmware using the Device Firmware Update (DFU) USB class. We have already covered how to setup the FRDM-K64F board in Updating device firmware using DFU in Zephyr Project on a FRDM-K64F board

Prerequisites for this tutorial

  • It is assumed that you have completed the Updating device firmware using DFU in Zephyr Project on a FRDM-K64F board tutorial to prepare your FRDM-K64F device

  • Mender client installed on a device and connected to a Mender server (see Mender Getting started)

  • In this tutorial we will be using a Raspberry Pi 3 device as a reference for a Linux device running Mender, but this should be easy to replicate using any other device

  • The device needs to have dfu-util installed

    • On a Debian based system you can run apt install dfu-util
    • In a Yocto Project setup you can add the dfu-util recipe to your image which is part of oe-core.

Overview

In this tutorial we have the K64-USB port on the FRDM-K64F board connected to one of the USB hosts ports on the Raspberry Pi 3.

This will allow us to dfu-util on the Raspberry Pi 3 to download firmware files to the FRDM-K64F board.

Step 0 - Prepare the Raspberry Pi 3 device

Prepare a Raspberry Pi 3 device making sure that it has Mender integrated and running. We can use the pre-built Raspbian image provided by Mender for this which can be found here:

wget https://d4o6e0uccgv40.cloudfront.net/2020-02-05-raspbian-buster-lite/arm/2020-02-05-raspbian-buster-lite-mender-2.2.0b1.img.xz

Flash the image to an SD card:

xzcat 2020-02-05-raspbian-buster-lite-mender-2.2.0b1.img.xz | sudo dd of=<path to device> bs=4M

NOTE! If you point to the wrong when executing the above command, you risk overwriting your workstation’s local or connected storage devices.

Plug the SD card in your Raspberry Pi 3 device and power it up.

Once the device has started we need to configure the Mender client to connect to a known Mender server. In this case we will use a Mender Professional account.

You can get your Mender Professional tenant token at the My organization page in Mender Professional.

Setup the Mender tenant token:

TENANT_TOKEN="<paste your token here>"

Configure the Mender client:

sudo mender setup \
    --demo \
    --device-type raspberrypi3 \
    --hosted-mender \
    --tenant-token ${TENANT_TOKEN}

Restart the Mender client:

sudo systemctl restart mender-client

Install dfu-util which is required by the DFU Update Module:

sudo apt-get update && sudo apt-get install dfu-util

Step 1 - Installing the DFU Update Module

Download the latest version of the DFU Update Module by running the following on the Raspberry Pi 3:

mkdir -p /usr/share/mender/modules/v3 && wget -P /usr/share/mender/modules/v3 https://raw.githubusercontent.com/mendersoftware/mender-update-modules/master/dfu/module/dfu && chmod +x /usr/share/mender/modules/v3/dfu

Step 2 - Getting the update artifacts

There are already a set of artifacts prepared based on the Device Firmware Update (DFU) and Updating device firmware using DFU in Zephyr Project on a FRDM-K64F board tutorials.

Download the archive containing the pre-built Artifacts by running the following on your PC:

wget https://d1b0l86ne08fsf.cloudfront.net/mender-k64f-update-artifacts/k64f-firmware-artifacts.tar.gz

Unpack the archive:

tar xvf k64f-firmware-artifacts.tar.gz

You should now have the following Mender Artifacts:

blinky-blue.mender
blinky-green.mender
blinky-red.mender

Inspecting one of the Artifacts we can see that is of an dfu type:

$ mender-artifact read blinky-blue.mender
Mender artifact:
 Name: blinky-blue
 Format: mender
 Version: 3
 Signature: no signature
 Compatible devices: '[raspberrypi3]'
 Provides group:
 Depends on one of artifact(s): []
 Depends on one of group(s): []
 State scripts:

Updates:
   0:
   Type:   dfu
   Provides: Nothing
   Depends: Nothing
   Metadata: Nothing
   Files:
     name:     signed-blinky-blue.bin
     size:     13548
     modified: 2020-03-06 13:34:28 +0100 CET
     checksum: 3350fc78c6bbe946ddfca2fc5630a0f1728281bddde26c3e870a547ac2357f59

These Artifacts can now be uploaded to the Mender server and one can create a proxy deployment to the FRDM-K64F device using Mender.

Conclusion

In this tutorial we have demonstrated the possibility of using Mender to proxy firmware updates to external components.

The setup we have used in the tutorial supports end-to-end verification, as the Mender client is able to verify the signature of the Mender Artifact, and MCUboot used on the FRDM-K64F is also able to verify the signature of the provided update images. Additionally MCUboot is able to verify the signature on each boot, meaning that it is able to detect tampering of the firmware.

Obviously the communication between the Mender client and the Mender server are also encrypted (TLS) which adds an extra layer of security that you can leverage when you proxy the firmware update.


If this tutorial was useful to you, please press like, or leave a thank you note to the contributor who put valuable time into this and made it available to you. It will be much appreciated!

Hi @mirzak,
its okay to update firmware with FRDM-K64F device connected to a Raspberry Pi 3.

but i want to test the firmware update in raspberrypi3 itself(raspbian buster image) with mender is there any possibility to do that any help on that or any link which i can follow.

thanks & regards
arun

Hi @arun

Of course we support that. :wink: See Raspberry Pi 3 Model B/B+ Raspbian for more details

Drew

Hi. I have a question that is closely related to that topic. Currently I am realizing a prototype consisting of a Raspberry Pi 3b+ (running Mender) and an additional device connected to the Raspberry Pi over CAN bus. Basically, the RaspberryPi can update the firmware of the device connected to it (executing a Python script that I realized).
My idea is to use the RaspberryPi as a proxy: once the new firmware is received, I want the Python script to be executed automatically. The system is meant to be used by human beings.
Basically I am missing two features:

  1. how the Python script can be started automatically after the new firmware is received at Raspberry side using Mender? I guess that the most simple option (as the user interact with the Raspberry Pi) would be to realize an “application” running on the Raspberry Pi that the user can execute to check if updates have been released on the Mender server; if yes, the firmware is downloaded and the Python script used to flash the firmware is executed. This would require the possibility to “avoid update download if the user is not executing the application” at server side, and the possibility to mark (at server side) the update as failed if the “custom update application” does not exit as expected (e.g. the Python script is interrupted, or the device is not available e.g. due to a disconnection).
  2. there would be the need to have a list of “secondary devices” which do not run Mender client, but are associated to a device that run Mender. In my example, I would like to see the RaspberryPi listed on the server, and by clicking on it see that also an additional device is connected to the Raspberry. This is useful to see the software version that each device is running.
    I would like to specify that I have carefully read the guides on single file update, script update, and this one on proxy deployment of course. I am sorry for the long message, I hope everything is clear.
    Thank you in advance! :smiley: