Checking something with Documentation u-boot-fw-utils

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.

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,

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

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

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.

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.

Thanks for the heads up on that patch :slight_smile: