Mender blog

Notes from a user on Mender without Yocto

Arnstein Kleven, one of our Mender users, decided to use Mender for his board without using Yocto, and he was kind enough to share his notes from the experience! It's great to have an outside perspective on the challenges this presents. I have edited the raw notes slightly for easier reading, but otherwise this is straight from the community!

Note that this post assumes that you know the basics of Mender integration, and this post about porting Mender to a non-Yocto build system gives some additional background.

Files and paths that you will need on the device:

  • Executables:
    • /usr/bin/mender
    • /sbin/fw_printenv
    • /sbin/fw_setenv
    • /usr/share/mender/identity/mender-device-identity
    • /usr/share/mender/inventory/mender-inventory-hostinfo
    • /usr/share/mender/inventory/mender-inventory-network
  • Systemd file:
    • /lib/systemd/system/mender.service
  • Configs:
    • /etc/mender/mender.conf
    • /etc/mender/tenant.conf
    • /etc/mender/server.crt
    • /etc/fw_env.config
    • /etc/mender/artifact_info
    • /var/lib/mender/device_type

The Mender executable has to be compiled, as described in the blog post from last year. fw_printenv and fw_setenv will be created with U-boot, as described later. The 3 last executables can be found in the support folder in the mender repository.

The Mender Systemd file can be found in in the meta-mender repository.

The base config files can be found in this archive file (Editor: the tenant.conf is only needed if you are using the Mender hosted service). They all have an example in them, but will most likely need to be changed to fit your setup. tenant.conf should just be empty for now. The server certificate (server.crt) needs to be generated, as described in the documentation.

Configuring U-boot for Mender:

Apply the patches found in the meta-mender patch folder to your {uboot_folder}. Put the config_mender_defines.h file in {uboot_folder}/include, and change the values in it to reflect your setup (Editor: see this example on how this file is generated). If there is already a Mender U-boot patch for your board, apply it and you’re done.

If there is not already a Mender U-boot patch for your board, there are a couple things you need to do:

In the .h file for your board, make sure these are included:

#define CONFIG_BOOTCOUNT_LIMIT
#define CONFIG_BOOTCOUNT_ENV
#define CONFIG_ENV_IS_IN_MMC 1

If you have the environment in flash, CONFIG_ENV_IS_IN_MMC needs to be changed to CONFIG_ENV_IS_IN_FLASH etc.

You may need to add or remove other defines as well. config_mender.h will make sure to tell you what when you try to compile.

A generic boot command for a board is:

#undef CONFIG_BOOTCOMMAND
#define CONFIG_BOOTCOMMAND \
    "run mender_setup; " \
    "load ${mender_uboot_root} ${kernel_addr_r} ${mender_boot_root}/boot/Image; " \
    "load ${mender_uboot_root} ${fdt_addr_r} ${mender_boot_root}/boot/your_board.dtb; " \
    "setenv bootargs root=${mender_kernel_root} console=ttyFIQ0,1500000n8; " \
    "booti ${kernel_addr_r} - ${fdt_addr_r} ; " \
    "reset;\0" \
    "run mender_try_to_recover;"

Keep in mind that the booti command is used here. This is for loading 64-bit kernel images. If your kernel image is a zImage, you need to use bootz, and 32-bit kernel images use bootm. The console command will most likely need to be changed as well.

To get the fw_printenv and fw_setenv executables, run

make env 

in the U-boot folder. This will provide you with fw_printenv located in ${uboot_folder}/tools/env/. Put this file as fw_printenv and fw_setenv in /sbin , and make sure to add /sbin to your path by running

export PATH=$PATH:/sbin

Recent articles

An Overview of EU Cyber Resilience Act (CRA) Compliance

An Overview of EU Cyber Resilience Act (CRA) Compliance

Learn how the EU Cyber Resilience Act (CRA) enforces stringent cybersecurity requirements for PDEs. Explore compliance essentials in part 1 of 4
Mender versioning: New releases by component

Mender versioning: New releases by component

Explore Mender's shift to independent component releases and versioning, designed to enhance update speed and user clarity.
Driving secure innovation: ISO/SAE 21434 & UNECE compliance

Driving secure innovation: ISO/SAE 21434 & UNECE compliance

ISO/SAE 21434 and UNECE R155/R156 standards reshape cybersecurity in software-defined vehicles. Compliance with these frameworks is essential for protecting consumers, ensuring vehicle safety, and driving innovation in the automotive industry.
View more articles

Learn why leading companies choose Mender

Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.

 
sales-pipeline_295756365