On some cases, the actual number of bytes read can be shorter
than what was requested. This can be handled gracefully by
taking this difference into account instead of exiting.
Signed-off-by: NThibault Ferrante <thibault.ferrante@gmail.com>

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: 34255b92 ("tools: env: Add support for direct read/write UBI volumes")
Signed-off-by: NMartin Hundebøll <martin@geanix.com>

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: NSimon Glass <sjg@chromium.org>

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: NSimon Glass <sjg@chromium.org>

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: NIvan Mikhaylov <fr0st61te@gmail.com>

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: NHarald Seiler <hws@denx.de>

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: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

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: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

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: d3716dd6 ("env: Rename the redundancy flags")
Signed-off-by: NPierre-Jean Texier <pjtexier@koncepto.io>
Tested-by: NJoris Offouga <offougajoris@gmail.com>
Tested-by: NHeiko Schocher <hs@denx.de>
Suggested-by: NHeiko Schocher <hs@denx.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Since commit d3716dd6 ("env: Rename the redundancy flags"), the
definitions of ENV_REDUND_OBSOLETE & ENV_REDUND_ACTIVE was moved
to env.h.

Fixes:

tools/env/fw_env.c:122:22: error: ‘ENV_REDUND_ACTIVE’ redeclared as different kind of symbol
 static unsigned char ENV_REDUND_ACTIVE = 1;
                      ^~~~~~~~~~~~~~~~~
In file included from tools/env/fw_env.c:13:
include/env.h:63:2: note: previous definition of ‘ENV_REDUND_ACTIVE’ was here
  ENV_REDUND_ACTIVE = 1,
  ^~~~~~~~~~~~~~~~~
tools/env/fw_env.c:127:22: error: ‘ENV_REDUND_OBSOLETE’ redeclared as different kind of symbol
 static unsigned char ENV_REDUND_OBSOLETE;
                      ^~~~~~~~~~~~~~~~~~~
In file included from tools/env/fw_env.c:13:
include/env.h:62:2: note: previous definition of ‘ENV_REDUND_OBSOLETE’ was here
  ENV_REDUND_OBSOLETE = 0,
Signed-off-by: NPierre-Jean Texier <pjtexier@koncepto.io>
Tested-by: NJoris Offouga <offougajoris@gmail.com>
Tested-by: NHeiko Schocher <hs@denx.de>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Add an ENV prefix to these two flags so that it is clear what they relate
to. Also move them to env.h since they are part of the public API. Use an
enum rather than a #define to tie them together.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Move env_set() over to the new header file.
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

If flash_write fails, whilst we propagate this up to our caller, we need
to avoid swapping in the new file (if we're on a filesystem) in this
case.

Fixes: dbc34323 ("tools: env: Implement atomic replace for filesystem")
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

Signed-off-by: NPhilip Molloy <philip@philipmolloy.com>

addr0 is being freed twice, leading to segmentation fault
Signed-off-by: NBjörn Stenberg <bjorn@haxx.se>

As pointed out by Wolfgang Denk, the problem with this fix is that while
interactive users will see that we have found one part of the
environment failed and are using the other, progmatic use will not see
this and can lead to problems.
Signed-off-by: NTom Rini <trini@konsulko.com>

When using a redundant environment a read error should simply mean to
not use that copy instead of giving up completely. The other copy may
be just fine.
Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com>
Signed-off-by: NIoan-Adrian Ratiu <adrian.ratiu@ni.com>

's/environemnt/environment/' and
	's/Environemnt/Environment/'
Signed-off-by: NShyam Saini <shyam@amarulasolutions.com>

When reading the config file, or a script file, use getline rather than
fgets so line lengths aren't limited by the size of a compiled in buffer
(128 characters for config, 1024 for scripts).

Rename 'dump' to 'line' so it's clear we're working with a line of text.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: NTom Rini <trini@konsulko.com>

If the U-Boot environment is stored in a regular file and redundant
operation isn't set, then write to a temporary file and perform an
atomic rename.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

Extract write path of flash_io() into a separate function. This patch
should be a functional no-op.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: NStefano Babic <sbabic@denx.de>

Replace HaveRedundEnv with have_redund_env to fix style violation.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

Pass tools/env/fw_env.c through indent to correct style violations. This
commit consists of only one non-whitespace change:

  tools/env/fw_env.c:549: error: do not use assignment in if condition
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

Treat the first equal sign as a key/value separation too. This makes
the script files compatible with mkenvimage input file format. It
won't support variables with equal signs anymore, but this seems not
really like a loss.
Signed-off-by: NStefan Agner <stefan.agner@toradex.com>

The single argument `--noheader' is expecting isn't taken from getopt
parsing, but instead from the remaining argv arguments.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>

Remove unused ret from fw_env_flush.
Signed-off-by: NJelle van der Waa <jelle@vdwaa.nl>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Up to now we were able to read/write environment data from/to UBI
volumes only indirectly by gluebi driver. This driver creates NAND MTD
on top of UBI volumes, which is quite a workaroung for this use case.

Add support for direct read/write UBI volumes in order to not use
obsolete gluebi driver.

Forward-ported from this patch:
http://patchwork.ozlabs.org/patch/619305/

Original patch:
Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>

Forward port:
Signed-off-by: NS. Lockwood-Childs <sjl@vctlabs.com>

This support has been deprecated since v2017.09 due to security issues.
We now remove this support.
Signed-off-by: NTom Rini <trini@konsulko.com>

With the move of environment code from common/ to env/ a number of
changes needed to be made to various make targets.  We missed updating
some of the files required for out of tree builds of the tools.  Correct
the 'environ' target to know that we need to work under tools/env/ still
(not tools/environ/) and then update the wrappers in env_attr.c and
env_flags.c to point to the new correct file.
Reported-by: NPeter Robinson <pbrobinson@gmail.com>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

According to fsync specification [1] some special files (e.g., a pipe, FIFO,
or socket) don't support synchronization and return either EROFS or EINVAL.

On the linux side the sys_fsync -> do_fsync() checks if the requested file
has f_op->fsync defined. If not it returns EINVAL [2].

This commit prevents writing error messages for files (devices), which
do not support fsync().

[1] - http://man7.org/linux/man-pages/man2/fsync.2.html
[2] - http://elixir.free-electrons.com/linux/v4.13-rc6/source/fs/sync.c#L183Signed-off-by: NLukasz Majewski <lukma@denx.de>
Acked-by: NMichael Heimpold <mhei@heimpold.de>

We are now using an env_ prefix for environment functions. Rename setenv()
for consistency. Also add function comments in common.h.
Suggested-by: NWolfgang Denk <wd@denx.de>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Closing a file descriptor does not guarantee that the data has been
successfully saved to disk, as the kernel might defer the write.
Signed-off-by: NMichael Heimpold <mhei@heimpold.de>

If realloc fails we should release the old buffer.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NTom Rini <trini@konsulko.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

fw_env_open allocates buffers to store the environment, but these
buffers are never freed. This becomes quite nasty using the fw_ tools as
library, because each access to the environment (even just reading a
variable) generates a memory leak equal to the size of the environment.

Fix this renaming fw_env_close() as fw_env_flush(), because the function
really flushes the environment from RAM to storage, and add a
fw_env_close function to free the allocated resources.
Signed-off-by: NStefano Babic <sbabic@denx.de>

Move U-Boot private data into a separate file. This
lets export fw_env.h to be used by external programs
that want to change the environment using the library
built in tools/env.
Signed-off-by: NStefano Babic <sbabic@denx.de>

commit 183923d3 enforces that the
environment must start at an erase block boundary.

For block devices the sample fw_env.config does not mandate a erase block size
for block devices. A missing setting defaults to the full env size.

Depending on the environment location the alignment check now errors out for
perfectly legal settings.

Fix this by defaulting to the standard blocksize of 0x200 for environments
stored in a block device.
That keeps the fw_env.config files for block devices working even with that
new check.
Signed-off-by: NMax Krummenacher <max.krummenacher@toradex.com>

Suspected Spam: Do not open attachements![PATCH 4/6] tools/env: flash_write_buf: enforce offset to be start of environment

This allows to take advantage of the environment being block aligned.
This is not a new constraint. Writes always start at the begin of the
environment, since the header with CRC/length as there.
Every environment modification requires updating the header
Signed-off-by: NAndreas Fenkart <andreas.fenkart@digitalstrom.com>

flash_write_buf already looks up size/offset/#sector from struct
envdev_s. It can look up mtd_type as well. Same applies to
flash_read_buf. Makes the interface simpler
Signed-off-by: NAndreas Fenkart <andreas.fenkart@digitalstrom.com>