Checking something with Documentation u-boot-fw-utils

General Discussions
1

Hi,

I’m going through the board integration and have had to add a new recipe for u-boot-fw-utils as the vendor fork we are using doesn’t provide one. I’m following
https://docs.mender.io/2.1/devices/yocto-project/bootloader-support/u-boot/manual-u-boot-integration/providing-custom-u-boot-fw-utils#adapting-the-recipe

But was surprised to see

+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 ${S}/tools/env/fw_env.config ${D}${sysconfdir}/fw_env.config
+}

Where fw_printenv is installed twice, and the second time it is installed as fw_setenv. I’m just checking this is correct and that fw_printenv allows you to set environment variables or is this a typo and should be:
install -m 755 {S}/tools/env/fw_setenv {D}${base_sbindir}/fw_setenv

Best Regards,
Martin.

2

This is correct, and is a small quirk of the fw_setenv/fw_getenv binary as it will look at the name of the binary upon execution and based on that provide the desired functionality.

Also note, depending a bit on which Yocto version you are using. We provide a recipe for this,

https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender-auto-provided_1.0.bb

That will be used if you do not provide it on your own. This will enabled if you do not have anything set in the following variabels.

PREFERRED_PROVIDER_u-boot-fw-utils
PREFERRED_RPROVIDER_u-boot-fw-utils
3

Hi @martin yes it’s correct. fw_setenv and fw_printenv pointing to same binary and magic is done here: github

4

Thanks for clearing it up, I can see now that they are using the same codebase. Any reason why one isn’t a symlink to the other?

BTW: The auto-provided recipe compiled fw_printenv for the target and not the host. I tried to work out what was wrong but in the end I opted for a custom recipe. I had to use the following
EXTRA_OEMAKE_class-target = ‘CROSS_COMPILE={TARGET_PREFIX} CC="{CC} {CFLAGS} {LDFLAGS}" HOSTCC="{BUILD_CC} {BUILD_CFLAGS} ${BUILD_LDFLAGS}" V=1’
to get that to compile correctly. There is something odd about the vendor U-Boot that we are using I never got to the bottom of. Good news is that fw_printenv seems to be working as expected.

Cheers,
Martin.

5

Thanks for clearing it up, I can see now that they are using the same codebase. Any reason why one isn’t a symlink to the other?

I believe that a symlink would work just as good.

The auto-provided recipe compiled fw_printenv for the target and not the host.

Might relate that you need this patch (or a variant of it) in your custom U-boot fork.

6

Thanks for the heads up on that patch :slight_smile: