This has different semantics in different places. Go with the bootm method
and put it in a common function so that the behaviour is consistent in
U-Boot. Update the docs.
To be clear, this changes the way that 'bootelf' and standalone boot
work. Before, if autostart was set to "fred" or "YES", for example, they
would consider that a "yes". This may change behaviour for some boards,
but the only in-tree boards which mention autostart use "no" to disable
it, which will still work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>
Currently the env_get_f() function's return value behaves weirdly: it
returns the number of bytes written into `buf`, but whether this is
excluding the terminating NULL-byte or including it depends on whether
there was enough space in `buf`.
Change the function to always return the actual length of the value of
the environment variable (excluding the terminating NULL-byte) on
success. This makes it behave like sprintf().
All users of this function in U-Boot are compatible with this change.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
This function is a relic from the past when environment was read from
underlying device one character at a time.
It is used only in the case when getting an environemnt variable prior
relocation, and the function is simple enough to be inlined there.
Since env_get_char() is being changed to simple access to an array, we
can drop the failing cases and simplify the code (this could have been
done before, since env_get_char() did not fail even before).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
This function was used by other parts of U-Boot in the past when
environment was read from underlying device one character at a time.
This is not the case anymore.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
This function actually returns:
- the number of bytes written into @buf excluding the terminating
NULL-byte, if there was enough space in @buf
- the number of bytes written into @buf including the terminating
NULL-byte, if there wasn't enough space in @buf
- -1 if the variable is not found
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
It can be useful to use the same U-Boot binary for multiple purposes,
say the normal one, one for developers that allow breaking into the
U-Boot shell, and one for use during bootstrapping which runs a
special-purpose bootcmd. Or one can have several board variants that
can share almost all boot logic, but just needs a few tweaks in the
variables used by the boot script.
To that end, allow the control dtb to contain a /config/enviroment
node (or whatever one puts in fdt_env_path variable), whose
property/value pairs are used to update the run-time environment after
it has been loaded from its persistent location.
The indirection via fdt_env_path is for maximum flexibility - for
example, should the user wish (or board logic dictate) that the values
in the DTB should no longer be applied, one simply needs to delete the
fdt_env_path variable; that can even be done automatically by
including a
fdt_env_path = "";
property in the DTB node.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
If one of the reads fails when importing redundant environments (a
single read failure), the env_flags wouldn't get initialized in
env_import_redund(). If a user then calls saveenv, the new environment
will have the wrong flags value. So on the next load the new environment
will be ignored.
While debugging this, I also noticed that env/sf.c was not correctly
handling a single read failure, as it would not check the crc before
assigning it to gd->env_addr.
Having a special error path for when there is a single read failure
seems unnecessary and may lead to future bugs. Instead collapse the
'single read failure' error to be the same as a 'single crc failure'.
That way env_check_redund() either passes or fails, and if it passes we
are guaranteed to have checked the CRC.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Wolfgang Denk <wd@denx.de>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
split from env_import_redund() the part which checks
which Environment is valid into a separate function
called env_check_redund() and call it from env_import_redund().
So env_check_redund() can be used from places which also
need to do this checks.
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add another custom environment flag which discerns environment coming
from external storage from environment set by U-Boot itself.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add the new command 'env select' to force the persistent storage
of environment, saved in gd->env_load_prio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the new command env load to load the environment from
the current location gd->env_load_prio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Since commit af95f20 ("env: Create a new file for environment functions"),
a new header file exists.
So, this commit add a missing header file.
Fixes:
include/env.h:158:1: error: unknown type name ‘ulong’; did you mean ‘long’?
ulong env_get_ulong(const char *name, int base, ulong default_val);
^~~~~
long
include/env.h:158:49: error: unknown type name ‘ulong’; did you mean ‘long’?
ulong env_get_ulong(const char *name, int base, ulong default_val);
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Tested-by: Joris Offouga <offougajoris@gmail.com>
Tested-by: Heiko Schocher <hs@denx.de>
Acked-by: Joe 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: Simon Glass <sjg@chromium.org>
These definitions are effectively part of the 'public' API of the
environment implementation since they do not require access to any
internal variables. Move them to the env.h header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
This enum is somewhat widely used to determine if the environment is valid
or not. Move it to the common environment header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Move these functions to the new header file and rename set_default_env()
to env_set_default() so that it has a consistent env_ prefix.
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this function to the new header file and rename it so it has an env_
prefix.
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Move env_set_hex() over to the new header file along with env_set_addr()
which uses it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Move envmatch() over to the new header file. Also rename it to env_match()
to better line up with other functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Move this function over to the new header file. Also rename it to have an
env_ prefix like the other functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
At present we have environment.h but this file includes all the
environment-related header files as well as internals such as
default_environment.
It seems desirable to have a new header to hold the commonly used
environment functions, so that most files can avoid including all of this
unnecessary stuff.
Create a new env.h header and move one function over to it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
