Easiest kernel update setup

General Discussions
,
1

Hi forum,
new to mender
but I already have a working and tested setup with a/b partitions for OS update. I have also read docs and other posts about this but I didn’t get it completely (since the relevant posts are dated years ago)

The question is:
Which is the mender way to update not only the rootfs but the kernel too?

The context is emmc memory, extlinux.conf, the relevant partitions are:

|-mmcblk1p6 179:6 0 64M 0 part /uboot [ extlinux.conf, zImage..]
|-mmcblk1p7 179:7 0 912M 0 part / [active rootfs]
|-mmcblk1p8 179:8 0 912M 0 part [inactive rootfs]
|-mmcblk1p9 179:9 0 1.7G 0 part /data [shared data]

Now, do i have to try to create for instance a boot.ext4 to add to .mender artifact? or do i have to create a custom module that deals this /uboot partition?
Calling the kernel from roots is still the intended solution?

PS: I am working on a Yocto environment
Edit: I have no secure boot needs atm

Thanks is advance!

2

Hi @MatMender,

How did the specific board integration be created? Is this a Yocto build, mender-convert or something else entirely?

Unless you did something really unusual, the kernel is loaded from the root filesystem and therefore updated along that. You can verify that by looking at the bootscripts, which can be dumped by fw_printenv.

The fact that you have a zImage in \uboot indicates that the board integration might indeed be either incomplete, and the kernel being loaded from the boot partition, or that the kernel file is unintentionally duplicated, the file on the boot partition being an unnecessary orphan.

If you can share more details on the board, the build process and the (u-boot) integration, these questions can usually be solved really quickly.

Greetz,
Josef

3

Good morning @TheYoctoJester ,
sure, I’am using stm32mpu with openstlinux, some bsp custom layer, the mender layers are ‘meta-mender’ and ‘meta-mender-community’ (this one with some customization).
The partition scheme resulting from the the sum of these layers is a uboot partition + uboot env partition + dual a/b rootfs (excluding tf-a/optee parts for the sake of simplicity). No particular requirements on secure boot at the moment.
So yes, I was already working on moving ‘uboot partition’ contents like zImage, Dtb, extlinux.conf inside rootfs, along u-boot modifications of env variables to boot from rootfs.
But my doubts are at a more higher point of view, let’s say in term of which is the best practice to have mender fully working either with service or standalone update process.
For instance when I switched to rootfs boot option i noticed that i have to set both a/b partitions to bootable to allow u-boot to start from there, hence i was wondering if there are other things I have to take care of.
This is just to speedup the mender layer evaluation since is the first time i use it.

4

Hi @MatMender,

So generally speaking, there is no difference between standalone and managed mode. So if you have the integration working and verified for one case, then the other one is perfectly covered too.

As I do not know what exactly you are doing - if there are no company secrets involved, consider just showing your build configuration either here or via some git hosting - just a few things you can look into.

Maybe also @leon-anavi has additional pointers, as he has actual hands on experience with the STMs which I have not.

Greetz,
Josef

5

Ok, trying to be concise,
thank you for the attention,
yes it’s an evaluation company related, so full share is not a choice but i guess i can share part of local.conf.

  1. I started from here (partitions):
  • ft-a/optee/metadata/u-boot
  • u-boot-env [environment for u-boot, p5]
  • uboot [ not real u-boot place but a place where there was uImage, dtb]
  • rootfs [ linux ]
  • other st partitions [unused mostly]
  1. I succesfully tested this (first mender attempt) [.gptimg + .mender]:
  • ft-a/optee/metadata/u-boot
  • u-boot-env [environment for u-boot, p5]
  • uboot [ extlinux.conf , zImage, dtb p6]
  • dual rootfs a/b [active inactive linux, so no kernel update only OS ]
  • data
  1. I am working on this (to have also kernel in rootfs support) [.gptimg + .mender]:
  • ft-a/optee/metadata/u-boot
  • u-boot-env [environment for u-boot, p5]
  • dual rootfs a/b (linux with extlinux.conf, kernel + OS updates)
  • data

Present issues on config. 3 (since the time put on this is just a few hours ):

  • I am struggling on removing uboot p6 since mender-helpers.bbclass and mender-bootimg.bbclass are triggered maybe from .gtpimg and they want uboot partition to mount on rootfs(removed) but also bootfs (i don’t have it anymore but the ask fot it ).

What is ok on config 3:

  • Well I have /boot/extlinux + zImage and dtb in place ready for booting ( u-boot should be able to handle extlinux.conf from inside rootfs after proper config) available at rootfs/boot

Part of local.conf, a bit experimental so it might be a little dirty:

=========================================================================

# Mender

# =========================================================================

INHERIT += "mender-full"

MENDER_STORAGE_DEVICE = "/dev/mmcblk1"

MENDER_ARTIFACT_NAME = "release-1"

# testing locally

# MENDER_SERVER_URL = "https://your-mender-server"

MENDER_BOOT_PART_SIZE_MB = "0"

MENDER_DATA_PART_SIZE_MB = "128"

VIRTUAL-RUNTIME_init_manager = "systemd"

INIT_MANAGER="systemd"

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

VIRTUAL-RUNTIME_initscripts = ""

# KERNEL_DEVICETREE = "st/stm32mp135d-ugea-microdev-mx.dtb"

INITRAMFS_MAXSIZE = "524288"

# Disable GRUB on ARM

MENDER_FEATURES_ENABLE:append = " mender-uboot mender-image-gpt"

MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi"

# In file ./meta-st-stm32mp/conf/machine/include/st-machine-common-stm32mp.inc,

# EXTRA_IMAGECMD_ext4 is defined to set a label based on the IMAGE_SUFFIX. But

# IMAGE_SUFFIX is set to an empty string in meta-mender which results in invalid

# arguments to the '-L' option.

#

# Just remove the '-L' argument

EXTRA_IMAGECMD:ext4:remove = "-L"

# st-partitions-image is a customer image format that is used by the STM32MP BSP

# and it is not compatible with Mender image format requirements.

#

# Disable, as compatible image formats will be provided by meta-mender.

IMAGE_CLASSES:remove = "st-partitions-image"

# This is needed because we disable 'st-partitions-image' but this file will

# still have the dependencies on bootfs, vendorfs and userfs images.

WKS_FILE_DEPENDS:remove = "st-image-bootfs st-image-vendorfs st-image-userfs"

# Disable flashlayout config

#

# This generates a set of configuration files to be used by the STM32 flash tool,

# as the flash layout is not compatible with what we generate in Mender we can

# disable this.

#

# It also produces an build error if left enabled, as we have disabled build of

# the bootfs/vendorfs/userfs images which this configuration relies on.

ENABLE_FLASHLAYOUT_CONFIG = "0"

# STM32MP BSP defines a custom package called kernel-imagebootfs which contains

# the dtb and kernel files

#

# These are originally added in mender-setup-image.inc

MACHINE_ESSENTIAL_EXTRA_RDEPENDS:remove:mender-image:arm = "kernel-devicetree"

MACHINE_ESSENTIAL_EXTRA_RDEPENDS:append:mender-image:arm = " kernel-imagebootfs"

MENDER_STORAGE_TOTAL_SIZE_MB = "2048"

# # Upstream PR: https://github.com/STMicroelectronics/meta-st-stm32mp/pull/11

PREFERRED_PROVIDER_u-boot="u-boot-stm32mp"

PREFERRED_PROVIDER_virtual/bootloader="u-boot-stm32mp"

# Add custom image class that appends STM32MP bootloader to the gptimg

IMAGE_CLASSES += " stm32mp-gptimg"

MENDER_STORAGE_DEVICE_BASE = "/dev/mmcblk1p"

MENDER_BOOT_PART = ""

MENDER_BOOT_PART_MOUNT_LOCATION = ""

MENDER_BOOT_PART_MOUNT_LOCATION:mender-uboot = ""

MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}7"

MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}8"

PREFERRED_PROVIDER_mender = "mender-client"

MENDER_DATA_PART_NUMBER = "9"

MENDER_DATA_PART_SIZE_MB = "128"

IMAGE_FSTYPES:append = " gptimg.gz"

# extlinux.conf

KERNEL_IMAGETYPE = "zImage"

# IMAGE_BOOT_FILES = "kernel/zImage;boot/zImage kernel/stm32mp135d-ugea-microdev-mx.dtb;boot/stm32mp135d-ugea-microdev-mx.dtb extlinux.conf;boot/extlinux/extlinux.conf"

MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 = "0x1000000"

MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 = "0x1020000"

# Maps to CONFIG_SYS_MMC_ENV_DEV 1

MENDER_UBOOT_STORAGE_DEVICE = "1"

SYSTEMD_AUTO_ENABLE_mender-client = "disable"

# Exclude STM32MP fw_config to avoid conflict with Mender's libubootenv

IMAGE_INSTALL:remove = "u-boot-fw-config-stm32mp"

# extlinux.conf

# EXTRA_IMAGEDEPENDS += "bootfiles"

IMAGE_INSTALL:append = " bootfiles"
6

extra considerations,
i am also trying to keep the intermediate ‘uboot’ partition with only extlinux.conf pointing to rootfs kernel, dtb.
It could be a good compromise.

Briefly the following:
→ u-boot looks for bootable partitions
→ p6 with only extlinux.conf that points to
→ ${mender_kernel_root}/boot/zImage etc..

7

ok,
I Made some progress that fits my needs at the moment:

  • Dual a/b rootfs partition with os + kernel
  • No legacy (st) uboot partition
  • Uboot mods to bootcmd toward sysboot boot command

On this side I’d say we are ok!

1 Like
8

Hi @MatMender,

Nice to hear! In any case, a company-/product neutral guide or example setup would be very much appreciated so others can benefit from it too. I guess there is little patching involved, probably only the bootcmd, right?

Greetz,
Josef