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

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 device 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 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 operating 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.

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

Step 0 - Prepare the Raspberry Pi device

Prepare a Raspberry Pi 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:

For the Raspberry Pi 3:

wget https://d4o6e0uccgv40.cloudfront.net/2023-05-03-raspios-bullseye-armhf-lite/arm/2023-05-03-raspios-bullseye-armhf-lite-raspberrypi3-mender-convert-4.2.2.img.xz

For the Raspberry Pi 4:

wget https://d4o6e0uccgv40.cloudfront.net/2023-05-03-raspios-bullseye-armhf-lite/arm/2023-05-03-raspios-bullseye-armhf-lite-raspberrypi4-mender-convert-4.2.2.img.xz

Flash the image to an SD card:

For the Raspberry Pi 3

xzcat 2023-05-03-raspios-bullseye-armhf-lite-raspberrypi3-mender-convert-4.2.2.img.xz | sudo dd of=<path to device> bs=4M

For the Raspberry Pi 4

xzcat 2023-05-03-raspios-bullseye-armhf-lite-raspberrypi4-mender-convert-4.2.2.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 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 raspberrypi4 \
    --hosted-mender \
    --tenant-token ${TENANT_TOKEN}

In case of a Raspberry Pi 3, change --device-type to raspberrypi3

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:

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 for the Raspberry Pi 3.

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:
1 Like

Dear @giacomoravagli
Did you find a solution for your setup? I am considering something quite similar. I am especially interested if Mender is able to show software versions in the Mender Server of the “main” device (the one where mender client is running) and also software versions of “child” or “secondary” controllers which are connected to this main device?

Dear @mirzak
On a machine we plan to run an embedded linux with internet connectivity (maybe a Raspberry CM or similar) together with a companion microcontroller for the real-time control application. The real-time application is rather simple, I plan to use a bare-metal Rust application and no real-time OS like Zephyr. The microcontroller will not require a bootloader, it will just run the plain application. Do you suggest to use a custom module to perform the flashing of the microcontroller from the embedded linux device? Or what else do you suggest?
And the other question: Is it possible to see both software versions (embedded linux version and real-time app firmware version) in the Mender Server dashboard?

Thanks for your help!
Nico

Or maybe @drewmoseley you have a hint for me for the above questions? Thanks in advance!

Hi @nico,

I think using a custom update module here makes sense and I am pretty sure there is a way to see both versions after installing. @TheYoctoJester can you help further here?

Drew

@nico + @drewmoseley,

Thanks for the heads up! Yes, a custom update module makes perfect sense here. The way to see both artifacts in the device inventory is providing a custom device inventory script which gathers all the desired data and puts it into the inventory, therefore making it accessible on the management UI. Together with the custom column update that was rolled out recently this should have you covered.

Greetz,
Josef

Thanks a lot for that advice. I will look into the docs for the device inventory scripts. Have a good weekend!

A post was merged into an existing topic: Need to understand the integration of the mender-client with DFU