Re: fw_printenv says "Warning: Bad CRC, using default environment"
> On Feb 26, 2019, at 10:49 AM, Vagrant Cascadian <vagrant@debian.org> wrote:
>
> On 2019-02-26, Rick Thomas wrote:
>> On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
>> package) it says “Warning: Bad CRC, using default environment”.
>
> If when booting, it also gives you this message, that would suggest you
> have no saved environment for fw_printenv to read from, as it's using
> the default environment. I recommend not using "saveenv" or "fw_saveenv"
> for reasons described below...
>
>
>> The “default environment” is clearly *not* the environment that u-boot
>> is using to boot the box. At least the “ethaddr” variable in that
>> environment is clearly a fake one as show here:
>>
>>> root@cube:~# fw_printenv ethaddr
>>> Warning: Bad CRC, using default environment
>>> ethaddr=00:00:11:22:33:44
>>
>> This is definitely not the ethernet address that the box is using for dhcp.
>
> fw_printenv will only work if there's an environment saved; it doesn't
> read from u-boot’s built-in defaults.
So, if fw_printenv can’t see the environment that’s actually in use, what tool do you recommend for examining the u-boot environment from Linux?
>
> I generally recommend to avoid using "saveenv" and "fw_saveenv", since
> most modern boards work with distro_bootcmd and there are various
> options to configure the system at boot, such as boot scripts.
I presume you mean “fw_setenv” (there doesn’t seem to any “fw_saveenv” command in the “u-boot-tools” package)?
> Having a saved environment means you're stuck with whatever environment
> variables were present when you last ran "saveenv", which means any bugs
> fixed in newer versions of u-boot will still be present, and worst case,
> they might even be incompatible with the version of u-boot you're
> running. It will also happily save auto-detected variables.
>
> Additionally, "fw_saveenv" may require you to specify the entire
> environment to save, rather than just values you want to change.
So please help me understand this… If “saveenv” under u-boot is dangerous, and “fw_setenv” under Linux should not be used, what’s the purpose of having a persistent environment at all? Is it just a historical relic that has outlived it’s usefulness; or am I missing something subtle (more likely)?
>> A couple of more data points that may shed light on this:
>>
>>> root@cube:~# cat /etc/fw_env.config
>>> # Configuration file for fw_(printenv/saveenv) utility.
>>> # Up to two entries are valid, in this case the redundant
>>> # environment sector is assumed present.
>>> #
>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>> # sectors"
>>>
>>> # MTD device name Device offset Env. size Flash sector size
>>> /dev/mmcblk1p1 0x80000 0x2000
>
> This looks like a bug in your configuration; it should specify the raw
> device rather than a partition.
This is “fresh out of the box” configuration. I haven’t changed a thing. So, if this is wrong (which it clearly is) should I be reporting it as a bug in the “u-boot-tools” package? Where did this file come from? It doesn’t seem to be present in either of the “u-boot-tools” or “u-boot-imx” packages according to “dpkg-query -L”.
>>> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config
>>> # Configuration file for fw_(printenv/saveenv) utility.
>>> # Up to two entries are valid, in this case the redundant
>>> # environment sector is assumed present.
>>> #
>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>> # sectors"
>>>
>>> # MTD device name Device offset Env. size Flash sector size
>>> /dev/mmcblk0 0x80000 0x2000
>>
>> FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not
>> as either /dev/mmcblk0 or /dev/mmcblk1p1.
>
> Between versions of linux and u-boot the numbering of the devices may
> vary. In general, the numbering of such devices has gotten more stable
> over time, but it’s totally plausible that device numbers may vary.
Ah… I see. Would it make sense to note this fact in the comments?
>> Does this represent a bug in u-boot-tools, or am I mis-interpreting
>> something?
>
> My guess is just your misconfiguration above, and hopefully that you
> have no saved environment for the tools to read from.
As it turns out, I did do “saveenv” under u-boot — in hopes that I would be able to see it under Linux with fw_printenv. That didn’t work, of course — seemingly because of the above noted mis-configuration.
But not a problem… This is my “testing” machine — totally dedicated to the purpose, so I’ll just re-install from scratch the next time I want to test something.
> live well,
> vagrant
Thanks for all your help and good work!
Enjoy!
Rick
Reply to: