Raspberry Pi Compute Module 3

sumo
raspberrypi-cm3
yocto

#1

Board description

The Compute Module 3 is a Raspberry Pi 3 in a more flexible form factor, intended for industrial application which contains 4GB eMMC with combination of the BCM2837 processor and 1GB RAM.

URL: https://www.raspberrypi.org/products/compute-module-3/

Test results

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
thud (2.6) :test_works: :test_works: 1
sumo (2.5) :test_works: :test_works:

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

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 .

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="sumo"  

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

Next, initialize the build environment:

source setup-environment raspberrypi

Building the image

You can now proceed with building an image:

MACHINE=raspberrypi-cm3 bitbake core-image-base

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

Using the build output

  • tmp/deploy/images/raspberrypi0-wifi/core-image-base-raspberrypi-cm3.sdimg
  • tmp/deploy/images/raspberrypi0-wifi/core-image-base-raspberrypi-cm3.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 as described in Deploy to physical devices or by using the Mender client only in Standalone deployments.

Flash instructions

For flashing we need compute module io board V3 or custom hardware where module is attached.

Following setup will describe flashing sdimg to module by using Compute module IO board.

To store sdimg to eMMC we need to install usbboot tool which will mount eMMC on host computer. Tool can be fetched from usbboot. Follow instructions in Readme how to compile and install.

When installed run:

sudo ./rpiboot

Afterwards change J4 on compute module to position USB SLAVE and connect usb with host PC and power on board. After few seconds partitions of eMMC should appear. Then follow the official documentation on provisioning a new device to store sdimg to device.
When flashing is done disconnect usb from host PC and switch jumper back to BOOT ENABLE position.

References

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

Known issues

Boot firmware files

Raspberry Pi boards have a set of boot firmware files that are located on the vfat boot part, and a selection of these files are:

bootcode.bin  fixup.dat     fixup_cd.dat  fixup_db.dat
fixup_x.dat   start.elf     start_cd.elf  start_db.elf
start_x.elf

Occasionally there will be changes to the Raspberry Pi software stack that requires that these files are update. One example would be a change in the Linux kernel that relies on functional changes in the boot firmware and in this case you need to update the boot firmware together with the Linux kernel to get a functional device.

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

Also check out this workaround, note that it is unsafe to do this because there is no way you can update these files atomically and it is not possible to roll-back in case you install something that does not boot.

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.


Does mender change u-boot dts?
#2

Hi There,
Not sure how to edit a page, but here are two issues worth mentioning:

Currently the contents of the uboot partition (mmcblk0p1) will not be updated through mender. Files under here include the DTB files, uboot and the the kernel command line parameter file cmdline.txt.

Mender upgrades the kernel successfully by including a copy on the root filesystem and directs uboot to use this. However, a copy of the kernel uImage which came with the original sdimg will be located on the uboot partition, but not used.

Hope this helps.

BR,
Donal


#3

@DonalHEmb yes that is true and valid point. I think it should be added for all RPI based board not only this one. Some discussion about that topic: https://groups.google.com/a/lists.mender.io/forum/#!msg/mender/98PMIMUp8kA/haIrX1b1CwAJ

@mirzak what is your opinion about that? Thanks.


#4

Yes, we should definitely add this information under “Known Issues”. We have a lot of resources regarding this, so mostly copy/pasting :slight_smile:

Addition information can be found here, https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-raspberrypi

@DonalHEmb, everyone should be able to edit as long as you have an account. Should be an edit button at the bottom of the post. Please let me know if you can not see it.


#5

@mirzak, I’m logged in and only have like, link and bookmark icon/buttons along with a “Reply” button.


#6

@DonalHEmb, I increased your trust level. Can you see it now?


#7

@mirzak, yes I can, thank you.


#8

@DonalHEmb, I have posted some updates to the “Known Issues” section. Looks good?


#9

@mirzak, those changes look good. The only possible issue I can see is this statement, which is a little ambiguous to me:

“Typically there is something in the Linux kernel that requires something that is in the boot firmware. This means to update the Linux kernel you must also update the boot firmware files.”

It implies that you always need to update the boot firmware files if you change the kernel, which isn’t always the case.

Perhaps it could be re-written to:

For example, certain changes to the Linux Kernel can modify the boot firmware files. These boot firmware files will not be updated as part of the standard mender update process.