fw_printenv says "Warning: Bad CRC, using default environment"

[Rick Thomas]

On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools package) it says “Warning: Bad CRC, using default environment”.

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.

# 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
# 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.

Does this represent a bug in u-boot-tools, or am I mis-interpreting something?

Enjoy!
Rick

[Vagrant Cascadian]

Post by Rick Thomas
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...

Post by Rick Thomas
The “default environment” is clearly *not* the environment that u-boot
is using to boot the box. At least the “ethaddr” variable in that

Post by Rick Thomas
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.

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.

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.

Post by Rick Thomas

Post by Rick Thomas
# 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.

Post by Rick Thomas

Post by Rick Thomas
# 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.

Post by Rick Thomas
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.


live well,
vagrant

[Rick Thomas]

Post by Vagrant Cascadian

Post by Rick Thomas
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...

Post by Rick Thomas
The “default environment” is clearly *not* the environment that u-boot
is using to boot the box. At least the “ethaddr” variable in that

Post by Rick Thomas
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?

Post by Vagrant Cascadian
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)?

Post by Vagrant Cascadian
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)?

Post by Vagrant Cascadian

Post by Rick Thomas

Post by Rick Thomas
# 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”.

Post by Vagrant Cascadian

Post by Rick Thomas

Post by Rick Thomas
# 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?

Post by Vagrant Cascadian

Post by Rick Thomas
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.

Post by Vagrant Cascadian
live well,
vagrant

Thanks for all your help and good work!
Enjoy!
Rick

[Vagrant Cascadian]

Post by Vagrant Cascadian

Post by Rick Thomas
On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
package) it says “Warning: Bad CRC, using default environment”.

...

Post by Vagrant Cascadian
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 don't recommend using a tool from linux. Boot into u-boot and run
"printenv".

Post by Vagrant Cascadian
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)?

Correct.

Post by Vagrant Cascadian
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)?

There are valid uses of it, and if you know exactly what you're doing,
that's fine.

In general, I think it's better to use other methods to adjust the
environment at run-time (e.g. boot scripts).

Post by Vagrant Cascadian

Post by Rick Thomas

# 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”.

None of the u-boot packages install anything into /etc, so it's not a
bug in any of the u-boot packages. If something else installed it
without user intervention, it might be a bug in that package, but
whatever did it doesn't appear to be in any package in Debian:

https://codesearch.debian.net/search?q=fw_env.config

Post by Vagrant Cascadian

Post by Rick Thomas

# 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?

These are in the "examples" section for a reason, and the end-user needs
to adapt them to match their hardware configuration.

Post by Vagrant Cascadian

Post by Rick Thomas
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.

Indeed.

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.

Be sure to use a fresh microsd card or completely wipe it clean to avoid
many of the aforementioned issues.


live well,
vagrant

[Rick Thomas]

Post by Vagrant Cascadian

Post by Rick Thomas

Post by Vagrant Cascadian

Post by Rick Thomas
On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
package) it says “Warning: Bad CRC, using default environment”.

...

Post by Rick Thomas

Post by Vagrant Cascadian
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 don't recommend using a tool from linux. Boot into u-boot and run
"printenv".

Post by Rick Thomas

Post by Vagrant Cascadian
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)?

Correct.

Post by Rick Thomas

Post by Vagrant Cascadian
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)?

There are valid uses of it, and if you know exactly what you're doing,
that's fine.
In general, I think it's better to use other methods to adjust the
environment at run-time (e.g. boot scripts).

Post by Rick Thomas

Post by Vagrant Cascadian

Post by Rick Thomas

# 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”.

None of the u-boot packages install anything into /etc, so it's not a
bug in any of the u-boot packages. If something else installed it
without user intervention, it might be a bug in that package, but
https://codesearch.debian.net/search?q=fw_env.config

Post by Rick Thomas

Post by Vagrant Cascadian

Post by Rick Thomas

# 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?

These are in the "examples" section for a reason, and the end-user needs
to adapt them to match their hardware configuration.

Post by Rick Thomas

Post by Vagrant Cascadian

Post by Rick Thomas
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.

Indeed.

Post by Rick Thomas
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.

Be sure to use a fresh microsd card or completely wipe it clean to avoid
many of the aforementioned issues.
live well,
vagrant

Understood. Thank you for your patience and understanding with my questions!
Rick

Thomas' observation on progress bars:
"Anything with a progress bar will spend 90% of it's time with the progress bar registering 90% done."