The attribute of the a hex flag is 'x' iso 'h'.
The type attributes are:
s - String (default)
d - Decimal
x - Hexadecimal
b - Boolean ([1yYtT|0nNfF])
i - IP address
m - MAC address
It's correct though throughout the rest of the code.
Signed-off-by: Bartel Eerdekens <bartel.eerdekens@constell8.be>
strlen(flagsvar) is re-evaluated on each while-loop iteration.
As \0 string terminators are added, the loop ends prematurely,
stopping after the first introduced \0 string terminator.
Signed-off-by: Bartel Eerdekens <bartel.eerdekens@constell8.be>
Signed-off-by: Stefano Babic <sbabic@denx.de>
Some flashes have issue by locking/unlocking. The additional flag in
configuration file allows to disable the LOCK/UNLOCK mechanism in MTD.
Signed-off-by: Stefano Babic <sbabic@denx.de>
libuboot_set_env() already tests if '=' is in variable name and returns -EINVAL
in this case.
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Before this patch, it was possible to do the following:
fw_setenv '' foo
Which leads to having this in the environment:
=foo
Which in turns causes U-Boot to throw error when parsing environment.
Now, if the above command is given, an error code is returned and environment is
not modified.
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Library is using crc32(), therefore needs to link against zlib.
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Currently fsync() only gets called at the end of fileprotect(), which
only occurs on mmcblk devices. I am storing a U-Boot environment inside
a fat32 filesystem, so the fsync() call does not get hit, and so the new
environment may be lost if power is lost.
Instead always fsync after the write has completed, regardless of the
device type.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Acked-by: Stefano Babic <sbabic@denx.de>
U-Boot's setenv command has treated '=' as an illegal character since
2006[1]. Per the original commit there is some form of backdoor when
doing commands like 'setenv ethaddr=', which it seems reasonable for us
to avoid.
For me, I have problems with users accidentally running `fw_setenv
var=value` (as it's a common idiom in shell scripting) and fw_setenv
prints no error as it thinks user wanted to delete a variable named
'var=value'.
Detect and return an error in libuboot_set_env(). Also detect in
fw_setenv() so we can print a user-friendly error message.
[1] 471a7be7a0
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Acked-by: Stefano Babic <sbabic@denx.de>
* Adjust calculated usable envsize in case redundand environment is used.
Signed-off-by: Sava Jakovljev <sava.jakovljev@teufel.de>
Acked-by: Stefano Babic <sbabic@denx.de>
libuboot_configure() fails to initialise dev->offset from the envdevs
structure and also doesn't setup ctx->size as happens in
libuboot_read_config(); use the same logic as exists there.
Signed-off-by: Alex Kiernan <alexk@zuma.ai>
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Before commit ed1a53ec "Dont store to device if no value changes" it was
possible to fill an uninitialized or broken environment using the
command "fw_setenv -f <default-environment-file>". This was considered
to be a feature.
The problem occurs because fw_setenv will now skip writing the
environment in case no environment variables to be changed are passed to
fw_setenv.
This commit will fix this problem by always storing the environment if
loading the environment failed and a default environment was given.
Signed-off-by: Wang Xin <xin.wang7@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
Acked-by: Stefano Babic <sbabic@denx.de>
ctx->size would be correct from start of struct / environment,
however usable environment payload starts from data header (offsetdata)
Signed-off-by: Manuel Dipolt <manuel.dipolt@robart.cc>
Acked-by: Stefano Babic <sbabic@denx.de>
Environment lines are terminated with a single null byte, followed
by another null byte to terminate the env itself. Fix termination
in case where flags need saving.
Signed-off-by: Sami Hartikainen <sami.hartikainen@teleste.com>
If the U-Boot environment configuration file fw_env.config happens
to have specified a length larger than the actual file's size, the
result is an infinite loop. Hence, check read()'s return value for
being 0, meaning EOF, and return an error.
Signed-off-by: Christian Storm <christian.storm@siemens.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Trying to use fw_printenv/fw_setenv with
/sys/bus/i2c/devices/0-0050/eeprom always fails for me:
$ fw_printenv
Cannot read environment, using default
Cannot read default environment from file
$
The problem is that fileread() and filewrite() in src/uboot_env.c
read/write once, and callers treat it as error if they did read/write
fewer bytes than requested.
In C it is not an error if fewer bytes get read/written than requested,
the caller is supposed to retry with the remaining bytes until everything
is done or an error occurs.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Running realpath() directly on the name parsed from the env config file
fails in the special case of UBI volume syntax, e.g.
/dev/ubi0:env
^^^------ UBI volume name
That special case with UBI volume name is handled by ubi_update_name(),
which doesn't happen early enough for normalizing the device path.
With above example, libuboot_read_config() would attempt to normalize
"/dev/ubi0:env" which does not exist.
Separate out the path normalization into a helper function that splits
off any volume part (e.g. ":env") before trying to normalize the path,
then appends the volume part to the normalized path.
Signed-off-by: S. Lockwood-Childs <sjl@vctlabs.com>
Switching to realpath to detect where the environment is stored
generates much longer filenames. Increase the maximum size to 256.
Signed-off-by: Stefano Babic <sbabic@denx.de>
Some platform uses softlinks to the devices that hold environment
data. The mechanism used to read device type from config is not robust
in this case. Calculating the canonicalized absolute pathname of the
device could fix the problem.
Signed-off-by: Mathias Thore <mathias.thore@atlascopco.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
The return value from lseek is not checked correctly, causing that the
environment is not read or written if an offset is set.
Signed-off-by: Stefano Babic <sbabic@denx.de>
When fw_setenv is called, it could happen that the new value is same
with the old one, in which case, we should avoid storing data to
device.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Double close: caller of mtdread() is responsible to close the file
descriptor, remove close() calls from mtdread.
Signed-off-by: Stefano Babic <sbabic@denx.de>
This used to work in the fw-utils based on U-Boot itself.
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Reviewed-by: Stefano Babic <sbabic@denx.de>
The UBI_IOCVOLUP ioctl expects a __s64*, however the struct
uboot_flash_env.envsize is of type size_t, which depending on the
architecture may be only 4 bytes long and cause the ioctl to read a
bogus size value. This fixes this by converting the size_t envsize to
a int64_t and passing a ptr to that to the ioctl.
Signed-off-by: Markus Klotzbuecher <mk@mkio.de>
Acked-by: Stefano Babic <sbabic@denx.de>
Port of U-Boot commit f4742ca0fb94 ("allow negative offsets"):
==========
A negative value for the offset is treated as a backwards offset for
from the end of the device/partition for block devices. This aligns
the behavior of the config file with the syntax of CONFIG_ENV_OFFSET
where the functionality has been introduced with
commit 5c088ee841f9 ("env_mmc: allow negative CONFIG_ENV_OFFSET").
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
==========
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Acked-by: Stefano Babic <sbabic@denx.de>
Sector size is in fw_env.config, but it could be redundant because the
value can be detected at runtime via ioctl().
Signed-off-by: Stefano Babic <sbabic@denx.de>
The list is not released in the close and this cause a segfault if the
same context is reused (as it is supposed to be). Segfault does not
happen if the context is released and a new one is created.
Signed-off-by: Stefano Babic <sbabic@denx.de>
Oleksandr Kravchuk
Bartel Eerdekens
Stefano Babic
Jan Havran
Francis Laniel
Reto Schneider
Brandon Maier
Sava Jakovljev
Alex Kiernan
Wang Xin
Manuel Dipolt
Sami Hartikainen
Christian Storm
Adrian Bunk
S. Lockwood-Childs
Ming Liu
thomas
Kristian Amlie
Markus Klotzbuecher
Max Krummenacher
Pierre-Jean Texier' via swupdate