U-boot integration fails on custom i.MX35 board

General Discussions
, ,
1

Hi everyone!

I’m trying to integrate Mender to a custom board, but without success.
This is the output of bitbake:

| DEBUG: Executing shell function do_provide_mender_defines
| + echo u-boot-imx
| + fgrep mender-auto-provided
| + true
| + expr 1048576 % ( 524288 * 2 )
| + [ 0 -ne 0 ]
| + [ 1048576 -gt 1048576 ]
< | + [ -n ]
| + false
| + get_part_number_from_device /dev/ubi0_0
| + dev_base=unknown
| + printf %d unknown
| + part=0
| + MENDER_ROOTFS_PART_A_NUMBER=
| + bb_exit_handler
| + ret=1
| + echo WARNING: exit code 1 from a shell command.
| WARNING: exit code 1 from a shell command.
| + exit 1

It seems some variables are missing or wrong, but I have no idea which one.
These are the variables I defined. I’m not sure on whether I did all of these correctly as there is little information on the internet about raw flash support; I used thiscolibri-imx7 as a template.

ARTIFACTIMG_FSTYPE = “ubi”
MENDER_BOOT_PART_SIZE_MB ?= “3”
MENDER_DATA_PART_SIZE_MB ?= “200”
MENDER_IMAGE_BOOTLOADER_FILE = “uboot-atk-myimage.bin”
MENDER_MTDIDS ?= “nand0=mxc_nand”
MENDER_MTDPARTS ?= “mxc_nand:512k(SBL1),512k(SBL2),1m(u-boot),1m(u-boot-env),-(ubi),2m(bbt)”
MENDER_NAND_FLASH_PAGE_SIZE ?= “4096”
MENDER_PARTITIONING_OVERHEAD_KB ?= “0”
MENDER_PARTITION_ALIGNMENT ?= “524288”
MENDER_STORAGE_DEVICE ?= “/dev/ubi0”
MENDER_STORAGE_TOTAL_SIZE_MB ?= “2048”
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET ?= “0x200000”
MENDER_UBOOT_STORAGE_DEVICE ?= “0”
MENDER_UBOOT_STORAGE_INTERFACE ?= “ubi”
BOOTENV_SIZE ?= “0x40000”
BOOTENV_RANGE ?= “0x80000”
IMAGE_FSTYPES += “ubi”

Some additional information:
The Yocto version is thud, Mender version 2.2 (as I think this is the default for the thud branch)

It shoud also be noted that a fork of u-boot v15.10 with custom patches to support the processor is used. As the mender patches did not apply to this rather old version of u-boot, I manually applied them.

Maybe someone has a clue what I’m missing? I’d really appreciate some help!

2

Did you also use this?

INHERIT += "mender-full-ubi"
3

Yes, I included it in my local.conf. Sorry I forgot to mention this.

4

It’s hard to say. Does the bitbake log have any more details? What about the log.do_provide_mender_defines file in your tmp/work/ folder?

Drew

5

Can you try to set MENDER_STORAGE_DEVICE to ubi0 instead of /dev/ubi0?

6

That indeed omits the error I previously had, thank you very much!!:slight_smile:
I’ll report if I encounter any other errors I can’t solve by myself.

7

Hello again,

everything builds successfully, but I am still facing problems.

I flash the .ubimg file via nand erase.part and nand write.e, loading the .ubimg file from an SD-card.

However, I am not able to ubifsmount the rootfs afterwards, getting the following error:

=> ubi part ubi
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name “mtd=4”, size 2043 MiB) to ubi0
UBI: PEB size: 524288 bytes (512 KiB), LEB size: 520192 bytes
UBI: min./max. I/O unit sizes: 4096/4096, sub-page size 1024
UBI: VID header offset: 1024 (aligned 1024), data offset: 4096
UBI: good PEBs: 4084, bad PEBs: 2, corrupted PEBs: 0
UBI: user volume: 5, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 364630146
UBI: available PEBs: 2340, total reserved PEBs: 1744, PEBs reserved for bad PEB handling: 78
=> ubifsmount ubi0:rootfsa
Error reading superblock on volume ‘ubi0:rootfsa’ errno=-12!

Before integrating mender, this worked perfectly, and strangely enough, it also works when using an unpatched (meaning no mender stuff) version of u-boot with an .ubimg file generated including mender. So it seems the .ubimg file is ok, but u-boot got somehow broken after introducing mender.
Has someone encountered the same problem or has an idea what the reason might be?

It should be also noted that I at first I got this warning when building u-boot including mender:

o_provide_mender_defines: Detected U-Boot without support for direct read/write to UBI volumes. Mender normally expects this unless you have a custom setup. Consider backporting the patch at tools: env: Add support for direct read/write UBI volumes (34255b92) · Commits · U-Boot / U-Boot · GitLab to your U-Boot sources.

I applied the suggested patch (manually), the warning disappeared, but no change in behaviour of ubifsmount.

I’d again really appreciate some help!

8

Never mind, I found out the problem myself. I accidentally reduced the size of CONFIG_SYS_MALLOC_LEN; after changing it to the original size I am finally able to boot!

9

I still have one problem though regarding the u-boot environment:
It is directly in NAND where the mtd device u-boot-env lays, see the layout:

mxc_nand:512k(SBL1),512k(SBL2),1m(u-boot),1m(u-boot-env),2043m(ubi),2m(bbt)

But Mender thinks it’s in a ubi volume and therefore creates two volumes u-boot-env-1 and u-boot-env-2 in the resulting .ubimg file which I don’t need. Even worse, it overrides the custom fw_env.config file that I deploy in my custom u-boot-fw-utils recipe. See here the recipe:

SUMMARY = “U-Boot bootloader fw_printenv/setenv utilities”
require u-boot-common-imx.inc
require recipes-bsp/u-boot/u-boot-fw-utils-mender.inc

SRC_URI += " file://fw_env.config
"

INSANE_SKIP_${PN} = “already-stripped”
EXTRA_OEMAKE_class-target = ‘CROSS_COMPILE=${TARGET_PREFIX} CC=“${CC} ${CFLAGS} ${LDFLAGS}” HOSTCC=“${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}” V=1’
EXTRA_OEMAKE_class-cross = ‘ARCH=${TARGET_ARCH} CC=“${CC} ${CFLAGS} ${LDFLAGS} HOSTCC=”${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" V=1’

inherit uboot-config

do_compile () {
oe_runmake ${UBOOT_MACHINE}
oe_runmake env
}

do_install () {
install -d ${D}${base_sbindir}
install -d ${D}${sysconfdir}
install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_printenv
install -m 755 ${S}/tools/env/fw_printenv ${D}${base_sbindir}/fw_setenv
install -m 0644 ${WORKDIR}/fw_env.config ${D}${sysconfdir}/fw_env.config
}

do_install_class-cross () {
install -d ${D}${bindir_cross}
install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_printenv
install -m 755 ${S}/tools/env/fw_printenv ${D}${bindir_cross}/fw_setenv
install -m 0644 ${WORKDIR}/fw_env.config ${D}${sysconfdir}/fw_env.config
}

SYSROOT_PREPROCESS_FUNCS_class-cross = “uboot_fw_utils_cross”
uboot_fw_utils_cross() {
sysroot_stage_dir ${D}${bindir_cross} ${SYSROOT_DESTDIR}${bindir_cross}
}

PACKAGE_ARCH = “${MACHINE_ARCH}”
BBCLASSEXTEND = “cross”

PROVIDES_${PN} = “u-boot-fw-utils”
RPROVIDES_${PN} = “u-boot-fw-utils”

How can I tell Mender not to take care of where the u-boot environment is stored, since I do this myself?

10

Not sure, there is a way to override this. The UBI volumes are created here,

So the only way would be to disable mender-uboot DISTRO_FEATURE, but then you have to manually do everything that implies.

You can also create a customer image derived from https://github.com/mendersoftware/meta-mender/blob/thud/meta-mender-core/classes/mender-ubimg.bbclass#L83-L101.

Regarding the fw_env.config, you need to make sure this is not included in your environment,

11

Thank you for the quick response!

Thanks to your hint I found out it is enough to just rename my custom fw_env.config to fw_env.config.default, so Mender won’t create its own config file.

I was afraid there may be no easy way to override the UBI env volumes, but since they don’t do any harm (I hope?) I will leave them as is for now.

12

Sorry for bothering again, my original problem seems not to have been resolved. If I set

MENDER_STORAGE_DEVICE = “ubi0”

then everything compiles and bootes fine, but when I run mender from the command line, there is following error:

WARN[0000] Could not resolve path link: ubi0_0 Attempting to continue module=partitions
WARN[0000] Could not resolve path link: ubi0_1 Attempting to continue module=partitions

This is no wonder, as I can see in the auto-generated mender.conf that the paths are wrong:

{
“InventoryPollIntervalSeconds”: 1800,
“RetryPollIntervalSeconds”: 300,
“RootfsPartA”: “ubi0_0”,
“RootfsPartB”: “ubi0_1”,
“ServerURL”: “https://docker.mender.io”,
“TenantToken”: “dummy”,
“UpdatePollIntervalSeconds”: 1800
}

changing from ubi0_0 to /dev/ubi0_0 omits this error, but then mender -rootfs will not work.

If I otherwise set

MENDER_STORAGE_DEVICE = “/dev/ubi0”

I get the error described in my first post.

How can I correctly set different paths to the UBI volume for Linux and U-boot respectively ?
Searching through the docs made me think adding

MENDER_UBOOT_STORAGE_DEVICE = “0”
MENDER_UBOOT_STORAGE_INTERFACE = “ubi”

would do the trick, but there is no difference.

Do you have any advice ?

13

It turned out the warning can safely be ignored, as described here [MEN-3412] - Mender and CFEngine (by Northern.tech) Jira

The reason mender -rootfs did not work was that I had set

ARTIFACTIMG_FSTYPE = “ubi”

instead of

ARTIFACTIMG_FSTYPE = “ubifs”

Now everyhing works fine, thanks for the kind support!

1 Like
14

Thanks for reporting back, and glad it worked out for you!