u-boot.git/tools/env, branch master

tools: env: return error if ubi_update_start() fails

2021-01-22T21:58:55+00:00

The UBI_IOCVOLUP ioctl can fail if exclusive access to the volume isn't
obtained. If this happens, the flush operation doesn't return error,
leaving the caller without knowledge of missing flush.

Fix this by forwarding the error (-1) from ubi_update_start().

Fixes: 34255b92e6e ("tools: env: Add support for direct read/write UBI volumes")
Signed-off-by: Martin Hundebøll

tools: env: Avoid an uninited warning with was_locked

2020-08-05T12:18:34+00:00

Set this variable to 0 to avoid a warning about an unused variable. This
happens on gcc 7.5.0 for me.

Signed-off-by: Simon Glass

tools: env: Fix printf() warning in fw_env

2020-08-05T12:18:34+00:00

The printf() string produces a warning about %d not matching size_t. Fix
it and put the format string on one line to avoid a checkpatch warning.

Signed-off-by: Simon Glass

fw_setenv: lock the flash only if it was locked before

2020-07-31T14:13:00+00:00

With current implementation of fw_setenv, it is always locks u-boot-env
region if lock interface is implemented for such mtd device. You can
not control lock of this region with fw_setenv, there is no option for
it in config or in application itself. Because of this situation may
happen problems like in this thread on xilinx forum:
https://forums.xilinx.com/t5/Embedded-Linux/Flash-be-locked-after-use-fw-setenv-from-user-space
/td-p/1027851

A short summary of that link is: some person has issue with some spi
chip which has lock interface but doesn't locks properly which leads to
lock of whole flash memory on lock of u-boot-env region. As resulted
solution hack was added into spi-nor.c driver for this chip with lock
disablement.

Instead fix this problem by adding logic to fw_setenv only lock the
flash if it was already locked when we attempted to use it.

Signed-off-by: Ivan Mikhaylov

tools: fw_env: Fix warning when reading too little

2020-06-02T17:06:14+00:00

When using CONFIG_ENV_IS_IN_FAT and the config-file specifies a size
larger than what U-Boot wrote into the env-file, a confusing error
message is shown:

    $ fw_printenv
    Read error on /boot/uboot.env: Success

Fix this by showing a different error message when read returns too
little data.

Signed-off-by: Harald Seiler

tools/env/fw_env.h: remove env.h

2020-05-25T15:54:53+00:00

As reported by Nicolas Carrier on the Buildroot mailing list [1],
there is a new build issue while building a program which interacts with
the u-boot environment. This program uses the headers of the ubootenv
library provided by uboot-tools.

This is a recent change from uboot [2] adding "#include " to
fw_env.h. Adding env.h require a board configuration to build since
it also include compiler.h (and others uboot internal includes).

env.h include seems not needed since env_set() is not used in fw_env tool.

Nicolas removed env.h from fw_env tool and fixed it's build issue.

This problem is present since uboot v2019.10.

[1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html
[2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e

Reported-by: Nicolas Carrier 
Signed-off-by: Romain Naour

tools: fw_env: use erasesize from MEMGETINFO ioctl

2020-04-27T18:55:29+00:00

We have a board with several revisions. The older ones use a nor flash
with 64k erase size, while the newer have a flash with 4k sectors. The
environment size is 8k.

Currently, we have to put a column containing 0x10000 (64k) in
fw_env.config in order for it to work on the older boards. But that
ends up wasting quite a lot of time on the newer boards that could
just erase the 8k occupied by the environment - strace says the 64k
erase takes 0.405 seconds. With this patch, as expected, that's about
an 8-fold better, at 0.043 seconds.

Having different fw_env.config files for the different revisions is
highly impractical, and the correct information is already available
right at our fingertips. So use the erasesize returned by the
MEMGETINFO ioctl when the fourth and fifth columns (sector size and
#sectors, respectively) are absent or contain 0, a case where the
logic previously used to use the environment size as erase size (and
consequently computed ENVSECTORS(dev) as 1).

As I'm only testing this on a NOR flash, I'm only changing the logic
for that case, though I think it should be possible for the other
types as well.

Signed-off-by: Rasmus Villemoes

fw_setenv: avoid writing environment when nothing has changed

2019-12-20T16:02:24+00:00

In the case where one deletes an already-non-existing variable, or sets
a variable to the value it already has, there is no point in writing the
environment back, thus reducing wear on the underlying storage
device.

In the case of redundant environments, if the two environments
differ (e.g. because one is corrupt), make sure that any call of
fw_setenv causes the two to become synchronized, even if the fw_setenv
call does not change anything in the good copy.

Signed-off-by: Rasmus Villemoes 
Acked-by: Joe Hershberger

crc32: Use the crc.h header for crc functions

2019-12-02T23:23:08+00:00

Drop inclusion of crc.h in common.h and use the correct header directly
instead.

With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.

Signed-off-by: Simon Glass 
Reviewed-by: Tom Rini

fw_env: fix build error

2019-09-24T21:46:13+00:00

The following error appears:

tools/env/fw_env.c:1149:25: error: lvalue required as unary ‘&’ operand
  rc = write(fd, &ENV_REDUND_OBSOLETE, sizeof(ENV_REDUND_OBSOLETE));

Fixes: d3716dd ("env: Rename the redundancy flags")

Signed-off-by: Pierre-Jean Texier 
Tested-by: Joris Offouga 
Tested-by: Heiko Schocher 
Suggested-by: Heiko Schocher 
Acked-by: Joe Hershberger