Raspberry Pi 3 Model B/B+

Board description

The Raspberry Pi 3 Model B/B+ is a popular single board computer based on Broadcom SoCs. It is the most powerful board within the Raspberry Pi family and probably the most popular with “makers”.

770A5842-462x322

URL: https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus
URL: https://www.raspberrypi.org/products/raspberry-pi-3-model-b
Wiki: https://elinux.org/RPi_Hub

Test results

Raspberry Pi 3 is one of the official reference devices of Mender and is easy to get started with. This device is continuously tested as part of Mender testing pipelines which assures high quality of the integration.

The Yocto Project releases in the table below have been tested by the Mender community. Please update it if you have tested this integration on other Yocto Project releases:

Yocto Project Build Runtime
dunfell (3.1) :test_works: :test_works: 1
zeus (3.0) :test_works: :test_works: 1
warrior (2.7) :test_works: :test_works: 1
thud (2.6) :test_works: :test_works: 1
sumo (2.5) :test_works: :test_works:
rocko (2.4) :test_works: :test_works:

1. Disabled GRUB integration for ARM systems which is default in meta-mender. U-boot is still primary integration method for this board.

Build Means that the Yocto Project build using this Mender integration completes without errors and outputs images.
Runtime Means that Mender has been verified to work on the board. For U-Boot-based boards, the integration checklist has been verified.

Getting started

Prerequisites

  • A supported Linux distribution and dependencies installed on your workstation/laptop as described in the Yocto Mega Manual

    • NOTE. Instructions depend on which Yocto version you intend to use.
  • Google repo tool installed and in your PATH.

Configuring the build

Setup Yocto environment

Set the Yocto Project branch you are building for:

# set to your branch, make sure it is supported (see table above)
export BRANCH="dunfell"  

Create a directory for your mender-raspberrypi setup to live in and clone the
meta information.

mkdir mender-raspberrypi && cd mender-raspberrypi

Initialize repo manifest:

repo init -u https://github.com/mendersoftware/meta-mender-community \
           -m meta-mender-raspberrypi/scripts/manifest-raspberrypi.xml \
           -b ${BRANCH}

Fetch layers in manifest:

repo sync

Setup build environment

Initialize the build environment:

source setup-environment raspberrypi

Configure Mender server URL (optional)

This section is not required for a successful build but images that are generated by default are only suitable for usage with the Mender client in standalone mode, due to lack of server configuration.

You can edit the conf/local.conf file to provide your Mender server configuration, ensuring the generated images and Mender Artifacts are connecting to the Mender server that you are using. There should already be a commented section in the generated conf/local.conf file and you can simply uncomment the relevant configuration options and assign appropriate values to them.

Build for Hosted Mender:

# To get your tenant token:
#    - log in to https://hosted.mender.io
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
#
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "<copy token here>"

Building the image

You can now proceed with building an image:

MACHINE=raspberrypi3 bitbake core-image-base

Replace core-image-base with your desired image target.

Using the build output

After a successful build, the images and build artifacts are:

  • tmp/deploy/images/raspberrypi3/core-image-base-raspberrypi3.sdimg
  • tmp/deploy/images/raspberrypi3/core-image-base-raspberrypi3.mender

The disk image (with .sdimg suffix) is used to provision the device storage for devices without Mender running already. Please proceed to the official documentation on provisioning a new device for steps to do this.

On the other hand, if you already have Mender running on your device and want to deploy a rootfs update using this build, you should use the Mender Artifact files, which have .mender suffix. You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client standalone mode.

References

  • The template files that are used by this setup can be found in mender-mender-community

  • The Mender integration layer for Raspberry Pi boards can be found in meta-mender.

  • The official Mender documentation explains how Mender works. This is simply a board-specific complement to the official documentation.

Known issues

Boot firmware files

See Updating Raspberry Pi boot firmware files using Yocto Project and Mender.

See this thread where the limitations of the boot firmware files on Raspberry Pi are discussed.

Devicetree is not updated

To be able to support update of Linux kernel and devicetree, Mender requires these to be installed in the /boot directory for each rootfs (normally /dev/mmcblk0p2 and /dev/mmcblk0p3). On the other hand, the Raspberry Pi boot firmware requires that the DTB file is in the same partition as the boot firmware (/dev/mmcbl0p1) and the config.txt file. For now Mender will not use the DTB that is delivered with new artifacts and will continue to boot with the original DTB that was populated using the sdimg file.

Problem using ‘dtoverlay=pi3-disable-bt’

pi3-disable-bt disables the Bluetooth device and restores UART0/ttyAMA0 to GPIOs 14 and 15. It is also necessary to disable the system service that initialises the modem so it doesn’t use the UART

There is currently a known issue with above functionality, that is to enable UART0 on PIN 14 and 15.

It is actually not something that is caused by Mender specifically, but Mender requires U-boot to be present to support robust features such as roll-back. U-boot is typically not enabled if you do a stock Raspberry Pi and some people are often surprised that the Bluetooth UART stopped working when they integrate meta-mender.

The problem is in U-boot which does conflicting configuration, and there is a workaround reported here and it has been reported to U-boot but unclear when/if it will be fixed.


If this post 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!

2 Likes

3 posts were split to a new topic: Not able to login on Yocto image

4 posts were split to a new topic: Startup script for raspberrypi3 using yocto?

24 posts were split to a new topic: Issues with Raspberry Pi 3

A post was merged into an existing topic: Issues with Raspberry Pi 3

5 posts were merged into an existing topic: Issues with Raspberry Pi when updating rocko -> thud

13 posts were split to a new topic: Issues with Raspberry Pi when updating rocko -> thud

A post was split to a new topic: How can I edit the mender artifact, which I’ve built with mender

4 posts were split to a new topic: Raspberry Pi 3 build fails on warrior

2 posts were split to a new topic: Missing /data/mender/mender.conf when upgrading to warrior

3 posts were split to a new topic: Running Yocto build in containers gives “permission denied” error

I know this is a “how to get started”, but it might be worth adding when building the Yocto for Mender, you should also put in a unique release name. Otherwise, you’ll get multiple .mender files that that show up as the template text of “release-1” as you do more builds.

Here is what I did in my setup, I use what I’m building plus the date and time.

# The name of the disk image and Artifact that will be built.
# This is what the device will report that it is running, and different updates
# must have different names because Mender will skip installation of an Artifact
# if it is already installed.
MENDER_ARTIFACT_NAME = "rpi3-20220512-1956"
1 Like

@abartky I agree! Good idea, I’ll add it :slight_smile: