Yocto - u-boot-toradex-fsl-fw-utils don't work as expected


I added u-boot-toradex-fsl-fw-utils in my local.conf to add the possibility to manage the uboot variable directly from linux. The yocto compilation is ok (no error).
On Linux, after the boot I can access in the console to fw_printenv and setenv. But for example, when I try to read a variable (like vidargs or else) I got this issue

Warning: Bad CRC, using default environment
vidargs=mxc_hdmi.only_cea=1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:off video=mxcfb2:off  video=mxcfb3:off fbmem=32M

However, in u-boot the vidargs variable is set differently (and yes, I save the modiciation with saveenv)

Where I’m wrong ?

I executed the unlock script :

# Give fw_setenv mmcblk0boot0 write permissions
function fw_setenv() {
    echo 0 > /sys/block/mmcblk0boot0/force_ro
    /sbin/fw_setenv "$@"
    echo 1 > /sys/block/mmcblk0boot0/force_ro

Now the warning has disappeared and I’m able to setenv but the printenv still prints the default variable

What exact versions of things are we talking about? Please note that we lately changed certain details about where the boot loader and its environment are stored as can be seen from the release notes:

Linux Image V2.5 Beta 2 (November 6, 2015)
  - move environment to the end of the eMMC boot area before the config block

Should you now use a U-Boot boot loader using the older variant and user space fw_printenv/setenv utilities using the newer variant or vice versa I would imagine such strange behaviour. I would recommend for you to first try the same after updating everything to our latest regular BSP demo image and go from there.

Hi @marcel.ziswiler

It’s a good approach.

I flash directly via NFS the apalis that I reveive (differents variable are set by fw utils ). Maybe I can just changed the /etc/fw_env.config file to set up correctly the address. I’ll check it from your 2.5 BSP and create a .bbappend to specify the link of the modified file.
I can’t flash apalis that I receive with 2.5 version and then flash with my personal version (linux-toradex 3.14.28 base), it’s too long for my process.

I am not saying that you should do this for each and every module in your production. I am just saying that for now to understand the issue at hand I do recommend for you to stick to our standard demo image in order to get a feel for how fw_printenv/setenv is working. I would also recommend for you to updating all components (e.g. most importantly the U-Boot boot loader as well) to be based on the same and if at all possible our latest release even when going with your own custom build.

Well, depending on what exact Yocto stuff you build you will have to make sure to deploy an appropriate fwutils configuration e.g. as follows: http://git.toradex.com/cgit/meta-toradex.git/tree/recipes-bsp/u-boot/u-boot-toradex-fsl-fw-utils_git.bb?h=V2.5#n53


Warning: Bad CRC, using default environment

This means that fw_printenv did read the environment from storage but the CRC is wrong and it takes the default environment compiled into the fw_printenv binary.

This could have two reasons:
a) the environment have never been saved so far.
b) fw_env.config does not point to the location where the environment is stored.

If a) is the case and the defaults in fw_printenv are correct (e.g. you compiled if from the U-Boot version you use) then it is save to use fw_saveenv.

If b) is the case you will write the environment to a place in storage where it does not belong. If you’re lucky this will have no negative effects, if not the module might not boot or whatever…

If you stop in U-Boot and you execute saveenv you have a valid environment in storage. If you now use fw_printenv and the warning is not printed you have case a), if the warning is still there you have case b).


Oh ok. I guess that for the toradex boards that are never been modified (all u-boot variable are in factory mode), I’m in case a).

With your BSP it works fine (downloaded directly from http://developer1.toradex.com/files/toradex-dev/uploads/media/Colibri/Linux/Images/). There is however a message that indicates that the CRC is bad but by reading some topic on denx it’s normal (the flash hasn’t been initialized before the first operation.

My personnal version is based on 2.5b2 according to cat /proc/version. it’s possible that I get the wrong branch of the meta-toradex for uboot fw utils.

As you said, u-boot was not at the last vesrion (current version : ver=U-Boot 2015.04 (Dec 15 2015 - 15:58:10)). It works fine with 2.5b2. But after to flash with my rootfs deploy with yocto, the fw utils don’t work anymore … The message is Cannot parse config file: Invalid argument


I recently look at the link you have posted. It’s very useful. But I have another question :
When I try to print a u-boot variable with a brand new toradex (all is set from factory) I got this result :

root@apalis-imx6:~# fw_printenv vidargs
Warning: Bad CRC, using default environment
vidargs=mxc_hdmi.only_cea=1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M

The version is :

Linux version 3.10.17 (linuxdev@linuxdev.toradex.int) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11) ) #1 SMP Mon May 18 13:10:16 CEST 2015

On your repo, when I check the 2.4 branch (that corresponds with 3.10.17 version, unless I guess), the fw_env.config files are exactly the same.

So, despite of the “Warning Message”, is it safe to use fw_setenv ?

I fear there is no such fw_saveenv:

-sh: /sbin/fw_saveenv: No such file or directory.

linux: fw_printenv shows the changed vars
u-boot: printenv shows the old vars

Are there 2 different locations?
I use
/dev/mmcblk0 0x80000 0x2000
for apalis tk1


Which one might be the right one to write the u-boot env?

root@apalis-tk1:~# ls /dev/mmcblk*
/dev/mmcblk0 /dev/mmcblk0boot0 /dev/mmcblk0boot1 /dev/mmcblk0p1 /dev/mmcblk0p2 /dev/mmcblk0rpmb

As seen from
I fear that I have to update the u-boot suitable to my toradex kernel image, right?

Please create a new ticket with complete information such as which BSP version you are using etc.

For Apalis TK1 we typically use this fw_env.config.