Yocto: Rockchip separate kernel/rootfs layout

Hi all! I’m trying to setup mender on a Rockchip rk3399 board.
I’ve followed Rockchip’s guide for partitioning and flashing and it’s working for us.

Now I’ve followed mender’s guide (2.5) for integrating into our Yocto (warrior) build system.

Rockchip has their partition layout as follows:

  • p1 = loader (u-boot TPL+SPL)
  • p2 = u-boot
  • p3 = trust image
  • p4 = kernel (extlinux)
  • p5 = rootfs

I was going to change it to the following

  • p1 = loader
  • p2 = u-boot
  • p3 = trust
  • p4 = data
  • p5 = kernel
  • p6 = rootfs_a
  • p7 = rootfs_b

My first question is, what should I set MENDER_BOOT_PART to? Should it be set to partition 2?
My second question is, do I need to have the kernel and rootfs in the same partition?

I think partition 2 would be correct for MENDER_BOOT_PART but I’ve never seen a setup like this. In the default layout, are the loader and u-boot partitions actually mountable filesystems?

With Mender, the kernel is normally moved into the root filesystem so that it can easily be updated with a full rootfs update. The default Mender boot logic assumes that the kernel is in the rootfs and will load it from there.

If you want it in a separate partition you need to ensure that there are two for redundancy. One to match each of the two rootfs partitions. We don’t have out-of-the-box support for this. There is this layer which does have support for separate kernel partitions but I’ve never worked with it.


The loader and the u-boot partition are not mountable. Do they need to be?
The loader is the U-Boot TPL/SPL for initializing RAM and a jumping off point to U-Boot.
I’ll try out the layer you mentioned, but in case that doesn’t work is there a detailed image on the partition layout for eMMC/flash?

It depends on how uboot is configured. For instance on the Raspberry Pi, UBoot is actually a file on a fat partition so needs to be mountable. I don’t know about this platform though.

I’m not sure what you are looking for as far as a “detailed image”. The Mender layer is fairly configurable so as long as you have two rootfs partitions with appropriate Yocto variable settings you should be ok.

Yeah, so I’m working on trying to get everything configured properly for mender.
We have our own separate patches for the u-boot to do some additional configuration, but I’m having a hard time applying some of the patches from mender for u-boot.
Specifically right now is when we try to add kconfig options for CONFIG_ENV_OFFSET I end up with a python3 error:

  File "/poky/build/tmp/work/poky-linux/u-boot/1_2019.01-r0/add_kconfig_option_with_depends.py", line 38, in add_kconfig_option
    if re.match("^config\s*%s(\s|$)" % kconfig_key, line):
  File "/usr/lib/python3.6/re.py", line 172, in match
    return _compile(pattern, flags).match(string)
  File "/usr/lib/python3.6/re.py", line 301, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.6/sre_compile.py", line 562, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/lib/python3.6/sre_parse.py", line 855, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
  File "/usr/lib/python3.6/sre_parse.py", line 416, in _parse_sub
    not nested and not items))
  File "/usr/lib/python3.6/sre_parse.py", line 768, in _parse
    source.tell() - start)
sre_constants.error: missing ), unterminated subpattern at position 10 

If I print out the key and line variables at the place I see the following before it crashes

key=ENV_OFFSET, line=config ENV_OFFSET

key=ENV_OFFSET, line=	hex "Environment Offset"

key=ENV_OFFSET, line=	depends on (!ENV_IS_IN_UBI && !ENV_IS_NOWHERE) || ARCH_STM32MP

key=(!ENV_IS_IN_UBI, line=#

Does this patch help?


Actually the env/Kconfig has that section patched, but what’s different is the lines proceeding it

        hex "Environment Offset"
        depends on (!ENV_IS_IN_UBI && !ENV_IS_NOWHERE) || ARCH_STM32MP

The line with (!ENV_IS_IN_UBI …
is the line that caused the issue it seems.
If I patch tge add_kconfig_option_with_depends.py file as so, then it works fine

diff --git a/meta-mender-core/recipes-bsp/u-boot/files/add_kconfig_option_with_depends.py b/meta-mender-core/recipes-bsp/u-boot/files/add_kconfig_option_with_depends.py
index 549a27eb..e4834988 100644
--- a/meta-mender-core/recipes-bsp/u-boot/files/add_kconfig_option_with_depends.py
+++ b/meta-mender-core/recipes-bsp/u-boot/files/add_kconfig_option_with_depends.py
@@ -34,6 +34,8 @@ def add_kconfig_option(option):
                 kconfig_key = key[len("CONFIG_"):]
                 inside_option = False
                 for line in fd.readlines():
+                    kconfig_key = re.escape(kconfig_key)
+                    line = re.escape(line)
                     if re.match("^config\s*%s(\s|$)" % kconfig_key, line):
                         inside_option = True

To follow up, if the U-boot partition itself is not mountable then I assume the U-boot environment needs to be mountable, correct?

I also get an error when building the core-image-minimal, during the execution of do_image_sdimg
What am I missing here?

| output: /poky/build/tmp/work/poky-linux/core-image-minimal/1.0-r0/bootfs.image_sdimg/*: No such file or directory

I don’t think so. Normally the environment is just a raw block of flash data and not a filesystem.

No idea on that build error. Is there anything else in the build log of interest?

I think I solved the second problem, it looks like the rootfs/uboot partition was not being populated because IMAGE_BOOT_FILES was not defined. This topic helped me solve that problem:

Though, it begs the question as to why the u-boot.bin file needs to be included in the rootfs? I suppose I’m confused by what is required and what is not based on the guide.
Do I need to define these?
If so, how does Mender use them?

Those variables are used when the U-Boot image is stored in unpartitioned space. It sounds like in your case, the SPL/TPL image is expecting to load the full U-Boot image as a file in a FAT partition so you probably don’t need them defined.

The U-Boot image is actually a combination of a trust image and u-boot device tree (see attached image, right hand side). So it sounds like I would need to define those environments. Is that right, or did I misunderstand?

That sounds right but I have never worked with trusted boot so you may be better off checking in with one of the U-Boot mailing lists.


I’ll follow up with some of the maintainers of u-boot.
A separate question from that, how can I specify the kernel bootargs that mender should pass once the kernel is loaded?

It’s standard bootloader environment stuff.

If you are using U-Boot Mender integration then take a look at pre and post setup commands.

If you are using grub Mender integration then take a look at the grub-mender-grubenv recipe.