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
Attachment:
signature.asc
Description: PGP signature