Re: fw_printenv says "Warning: Bad CRC, using default environment"
On Tue, Feb 26, 2019, at 3:34 PM, Vagrant Cascadian wrote:
> On 2019-02-26, Rick Thomas wrote:
> >> 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”.
> ...
> >> 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".
>
>
> >> 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.
>
> >> 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).
>
>
> >>> 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”.
>
> 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
>
>
> >>>> 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?
>
> These are in the "examples" section for a reason, and the end-user needs
> to adapt them to match their hardware configuration.
>
>
> >>> 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
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."
Reply to: