Google Coral Dev Board

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

Board description

A development board to quickly prototype on-device ML products. Scale from prototype to production with a removable system-on-module (SoM).


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
warrior (2.7) :test_works: :test_works:

NOTE! This integration has only be tested using the SD card as boot medium and would require additional changes to support booting from e.g eMMC.

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


  • 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="warrior"

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

mkdir mender-coral && cd mender-coral

Initialize repo manifest:

repo init -u \
           -m meta-mender-coral/scripts/manifest-coral.xml \
           -b warrior

Fetch layers in manifest:

repo sync

Setup build environment

Initialize the build environment:

. setup-environment coral

NOTE! You need to accept the Freescale EULA at ‘…/sources/meta-freescale/EULA’. Please read it and to accept it run:

echo "ACCEPT_FSL_EULA = \"1\"" >> conf/local.conf

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 deployments, 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
#    - 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_TENANT_TOKEN = "<copy token here>"

Build for Mender demo server:

# Update IP address to match the machine running the Mender demo server

Building the image

You can now proceed with building an image:

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 placed in tmp/deploy/images/coral-dev/.

  • tmp/deploy/images/coral-dev/core-image-base-coral-dev.sdimg
  • tmp/deploy/images/coral-dev/core-image-base-coral-dev.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 only in Standalone deployments.


Known issues

NOTE! This integration has only be tested using the SD card as boot medium and would require additional changes to support booting from e.g eMMC.

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!


Hi @mirzak,

great work!

Do you have an idea what needs to be changed to support booting from mmc?

Best regards

1 Like

It might be as easy as adjusting,

MENDER_STORAGE_DEVICE = "/dev/mmcblk1"


MENDER_STORAGE_DEVICE = "/dev/mmcblk0"

Though I have not had a chance to test this yet, also the eMMC flash process somewhat convoluted if using the standard tools so it might be easier to flash the eMMC from a booted SD card.

1 Like

thanks, i will try this.
you’re right, I am currently struggling with uuu tool to flash anything to the device. Without luck so far. Will investigate further…

Hi guys, I’m Nam from the coral team, @ruben reached out to me so I wanted to come collect more info :slight_smile:

I never used mender before, but I saw that you can build this os to a .sdimg file? I wonder if this .sdimg is anyway different than a normal OS image and what’s the difference between this and the .mender file? Here something that may works (do this at your own risk):

  1. Connect your dev board to your machine with the serial cable and the USB-A to C cable.
  2. Boot up the board and press any key to put the board on u-boot prompt
  3. On the u-boot prompt, enter ums 0 mmc 0, this will mount the emmc on the board as a usb device on your host machine.
U-Boot# ums 0 mmc 0
  1. Make sure to check fdisk -l to get the correct usb device from the dev board (mine was /dev/sda).
  2. Important: back up the current MendelOS image so you won’t lose it:
$ sudo if=/dev/sda of=mendel_backup.img bs=4M status=progress
  1. Copy the mender disk image to the emmc
$ sudo dd if=path-to-mender-img of=/dev/sda bs=4M status=progress

It is advice to be very careful here because you can wipe out the wrong drive with the “of” parameter

That should be it, at least this works for backup the MendelOS image.
Although I’m a little nervous about giving this solution, because I’m not sure if the sdcard image will work with emmc. You may ends up not being able to boot to emmc at all after transferring that image over.

1 Like

Hi @Namburger, thank you for following up.

The .sdimg file is an ordinary OS image with some extra partitions due to Mender requirements (A/B structure). So this is something that you would write to e.g the SD card using similar dd commands as you mention.

On the u-boot prompt, enter ums 0 mmc 0 , this will mount the emmc on the board as a usb device on your host machine.

The ums approach is pretty nice and have used it on several other boards.

You may ends up not being able to boot to emmc at all after transferring that image over.

But it should be possible to restore the eMMC, right? I have not looked at it yet, but at least you could boot an SD card to flash eMMC and it seems like this is something that is recommend as well in docs

I will try to play around with the eMMC a bit and will update the instructions once done.

This is the update Artifact, and normally only contains a rootfs image. So this is something that you would deploy using a Mender server.

Yes, you can always use the recovery image here to flash into u-boot on an sdcard and then use the backup image on step 5 to restore your emmc. At least it works in theory :upside_down_face:

Hi @Namburger, hi @mirzak,

Thanks a lot for your responses!
I successfully flashed my image with the u-boot

ums 0 mmc 0

approach. I didn’t know this, pretty nice!

But after flashing and changing the boot switches to mmc nothing boots. No output on serial console.
Will investigate more on bootloader changes, perhaps wrong partition in bootloader config.

New results:

  • I flashed the new image with following change to sd

MENDER_STORAGE_DEVICE = “/dev/mmcblk0”

I checked the u-boot variable on old and new image and the changes affected the mmc location -> perfect!
I booted kernel and it uses the previously flashed image from mmc, not sd.

So the problem seems to be that after flashing to mmc spl loader is not found or in wrong place. Do you have any idea how this could happen?

I suspect that the bootloader is stored in the hardware boot partition on eMMC while this is not the case for SD.

Could you try writing the bootloader in a separate step running the following command on your PC:

fastboot flash bootloader0 u-boot.imx

Above is what is executed by the script provided by Coral for Mendel OS flashing.

The u-boot.imx is called imx-boot in Yocto deploy directory. Note that you need to start fastboot in U-Boot for this to work.

This can probably be accomplished using mmc write command in U-Boot as well, but would need to experiment with it to understand the offsets.

You can also take a look at Toradex Colibri iMX7 Dual 1GB (in the Flash instructions section), I would expect something similar could work here as well.

I flashed with both ways, fastboot and mmc write like toradex. Both didn’t work.
Now I will double-check all my steps and checking the boot mode settings again.

Next step would be to flash mendel os again and then only exchange imx-boot

Did a quick test on my board and it succeeded booting from eMMC, after I used fastboot to flash U-Boot.

So the steps that worked for me are:

  1. Flash SD card with an bootable image, insert to board and boot it
  2. Halt U-boot
  3. Run ums 0 mmc 0 in U-Boot
  4. Flash sdimg
  5. Run fastboot 0 in U-Boot
  6. Flash U-Boot by running fastboot flash bootloader0 imx-boot
  7. Powered off the board
  8. Adjusted boot switches for eMMC
  9. Power on board

Thanks a lot for detailed explanation. I will try tonight again. Guess I made mistake with boot switches. :frowning:

@mirzak now it is working! Thanks a lot for your help.
After flashing bootloader0 the first time i forgot to adjust the boot switches correctly. :face_with_hand_over_mouth:
Also thanks @Namburger for your help!

1 Like

Nice @ruben!
Thanks @mirzak for your expertise!