History log of /u-boot/env/env.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# d678a59d 18-May-2024 Tom Rini <trini@konsulko.com>

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 0f92fa45 27-Apr-2024 Tom Rini <trini@konsulko.com>

env: Remove <common.h> and add needed includes

Remove <common.h> from all "env/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

# decbc818 06-Sep-2023 Marek Vasut <marek.vasut+renesas@mailbox.org>

env: Remove unused NEEDS_MANUAL_RELOC code bits

The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

# 8344162e 01-May-2023 Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

env: Remove misuse of env is nowhere leftover

When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove leftover of
misuse of the env is nowhere driver as default environment.

Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

# 5ab81058 03-Feb-2023 Jan Kiszka <jan.kiszka@siemens.com>

env: Complete generic support for writable list

This completes what 890feecaab72 started by selecting ENV_APPEND and
loading the default env before any other sources. This ensures that load
operations pick up all non-writable vars from the default env and only
permitted parts from other locations according to the regular
priorities.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
CC: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Marek Vasut <marex@denx.de>

# 65a7310d 01-Feb-2023 Simon Glass <sjg@chromium.org>

env: Drop ENV_IS_IN_SATA

This is not used anywhere, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.prasad.paladugu@amd.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 0f92fa45 27-Apr-2024 Tom Rini <trini@konsulko.com>

env: Remove <common.h> and add needed includes

Remove <common.h> from all "env/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

# decbc818 06-Sep-2023 Marek Vasut <marek.vasut+renesas@mailbox.org>

env: Remove unused NEEDS_MANUAL_RELOC code bits

The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

# 8344162e 01-May-2023 Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

env: Remove misuse of env is nowhere leftover

When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove leftover of
misuse of the env is nowhere driver as default environment.

Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

# 5ab81058 03-Feb-2023 Jan Kiszka <jan.kiszka@siemens.com>

env: Complete generic support for writable list

This completes what 890feecaab72 started by selecting ENV_APPEND and
loading the default env before any other sources. This ensures that load
operations pick up all non-writable vars from the default env and only
permitted parts from other locations according to the regular
priorities.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
CC: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Marek Vasut <marex@denx.de>

# 65a7310d 01-Feb-2023 Simon Glass <sjg@chromium.org>

env: Drop ENV_IS_IN_SATA

This is not used anywhere, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.prasad.paladugu@amd.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# decbc818 06-Sep-2023 Marek Vasut <marek.vasut+renesas@mailbox.org>

env: Remove unused NEEDS_MANUAL_RELOC code bits

The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

# 8344162e 01-May-2023 Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

env: Remove misuse of env is nowhere leftover

When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove leftover of
misuse of the env is nowhere driver as default environment.

Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

# 5ab81058 03-Feb-2023 Jan Kiszka <jan.kiszka@siemens.com>

env: Complete generic support for writable list

This completes what 890feecaab72 started by selecting ENV_APPEND and
loading the default env before any other sources. This ensures that load
operations pick up all non-writable vars from the default env and only
permitted parts from other locations according to the regular
priorities.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
CC: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Marek Vasut <marex@denx.de>

# 65a7310d 01-Feb-2023 Simon Glass <sjg@chromium.org>

env: Drop ENV_IS_IN_SATA

This is not used anywhere, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.prasad.paladugu@amd.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 8344162e 01-May-2023 Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

env: Remove misuse of env is nowhere leftover

When using a list of writeable variables, the initial values come from
the built-in default environment since commit 5ab81058364b
("env: Complete generic support for writable list"). Remove leftover of
misuse of the env is nowhere driver as default environment.

Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>

# 5ab81058 03-Feb-2023 Jan Kiszka <jan.kiszka@siemens.com>

env: Complete generic support for writable list

This completes what 890feecaab72 started by selecting ENV_APPEND and
loading the default env before any other sources. This ensures that load
operations pick up all non-writable vars from the default env and only
permitted parts from other locations according to the regular
priorities.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
CC: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Marek Vasut <marex@denx.de>

# 65a7310d 01-Feb-2023 Simon Glass <sjg@chromium.org>

env: Drop ENV_IS_IN_SATA

This is not used anywhere, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.prasad.paladugu@amd.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 5ab81058 03-Feb-2023 Jan Kiszka <jan.kiszka@siemens.com>

env: Complete generic support for writable list

This completes what 890feecaab72 started by selecting ENV_APPEND and
loading the default env before any other sources. This ensures that load
operations pick up all non-writable vars from the default env and only
permitted parts from other locations according to the regular
priorities.

With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.

CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
CC: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Marek Vasut <marex@denx.de>

# 65a7310d 01-Feb-2023 Simon Glass <sjg@chromium.org>

env: Drop ENV_IS_IN_SATA

This is not used anywhere, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 1c44d108 14-Dec-2022 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_erase

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env erase' is not executed as it is
done in env_save with commit 8968288cb477 ("env: add failing trace in
env_save")

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <kabel@kernel.org>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# de70e887 05-Apr-2022 Marek Vasut <marex@denx.de>

env: Implement lower priority arch_env_get_location()

Currently there is only one way to override desired environment location,
by implementing env_get_location(). This is increasingly being conflated
both on board level and architecture level, which leads to a problem on
boards where this function is already implemented on architecture level,
since those boards have no way to override this environment location on
board level anymore.

Implement arch_env_get_location() function which is architecture specific
and should only ever be implemented in architecture code. This function
has lower priority than env_get_location(), which should only ever be
implemented in board code, and which overrides the arch_env_get_location()
architecture environment selection.

This way, architecture can define its default environment chooser, while
board can now override it as needed at all times.

There is no functional change, since env_get_location() simply returns
arch_env_get_location(), and arch_env_get_location() implements the
current env_get_location() default content.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tommaso Merciai <tomm.merciai@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 5c7399ec 09-Apr-2022 Marek Vasut <marex@denx.de>

Revert "env: Load env when ENV_IS_NOWHERE is only location selected"

This reverts commit 8d61237edbf6314a701cf78da2c5893a73ff5438.

This commit broke environment on literally every board I have access
to, with this revert in place, environment works as it should again.
The problem I observe with this patch is that saved environment in
either SPI NOR or eMMC is never used, the system always falls back
to default environment. The 'saveenv' command does succeed, but then
after reset, the default env is again used.

Furthermore, the commit introduced duplicate code in env_init(), this:
"
if (!prio) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}

if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
gd->env_valid = ENV_INVALID;

return 0;
}
"

Furthermore, the commit is missing DCO SoB line.

Also note that upstream does not support UltraZed EG board, so
this might have been a patch pulled from downstream which did
depend on some other downstream behavior.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Felix.Vietmeyer@jila.colorado.edu <felix.vietmeyer@jila.colorado.edu>
Cc: Tom Rini <trini@konsulko.com>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 8d61237e 20-Apr-2021 Felix.Vietmeyer@jila.colorado.edu <Felix.Vietmeyer@jila.colorado.edu>

env: Load env when ENV_IS_NOWHERE is only location selected

This patch prevent u-boot from hanging on a UltraZed EG board (zynqmp).

Without the patch,
(drv = env_driver_lookup(ENVOP_INIT, prio))
evaluates to 0, causing prio = 0
Then, (!prio) is hit, returning -ENODEV causing a stall.

With the patch,
instead of returning -ENODEV and causing a stall, we
set gd->env_addr (is this really needed?)
and then
mark gd->env_valid = ENV_INVALID to use the default env.

# 52f9ed34 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 52f9ed34 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Inline env_get_char() into its only user

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>

# dd1c5a7f 17-Oct-2021 Marek Behún <marek.behun@nic.cz>

env: Drop env_get_char_spec() and old, unused .get_char() implementations

Commit b2cdef4861be ("env: restore old env_get_char() behaviour")
dropped the .get_char() method from struct env_driver, but left the two
existing implementations (eeprom and nvram) in case someone would use
them by overwriting weak function env_get_char_spec().

Since this was never done in the 3.5 years, let's drop these methods and
simplify the code.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 5557eec0 20-Jan-2021 Marek Vasut <marex@denx.de>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 401d1c4f 30-Oct-2020 Simon Glass <sjg@chromium.org>

common: Drop asm/global_data.h from common header

Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@foss.st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 46ce9e77 03-Nov-2020 Heiko Schocher <hs@denx.de>

env: sf: fix init function behaviour

Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.

reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.

Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.

env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.

This prevents that each environment driver needs to set the
default environment.

Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation")
Reported-by: Michael Walle <michael@walle.cc>
Tested-by: Michael Walle <michael@walle.cc> [For the SF environment]
Signed-off-by: Heiko Schocher <hs@denx.de>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 47f3b1f2 07-Jul-2020 Marek Vasut <marex@denx.de>

env: Add option to only ever append environment

Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a97d22eb 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

cmd: env: add env select command

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>

# 0115dd3a 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

cmd: env: add env load command

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>

# 466d9855 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: the ops driver load becomes mandatory in struct env_driver

The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 6d8d8400 28-Jul-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: correctly handle env_load_prio

Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).

This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 8968288c 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: add failing trace in env_save

Add trace in env save to indicate any errors to end user and avoid
silent output when the command 'env save' is not executed.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# d5a6a5a9 24-Jun-2020 Patrick Delaunay <patrick.delaunay@st.com>

env: correct overflow check of env_has_init size

Correct the overflow check of the bit-field env_has_init with
the max value of env_location= ENVL_COUNT and no more with the
size of env_locations.

This bit-field is indexed by this enumerate and not by the position in
the env_locations (only used in env_get_location) and the
2 values are different, depending of thea ctivated CONFIG_ENV_IS_ options.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# cd93d625 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eb41d8a1 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop linux/bug.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f7ae49fc 10-May-2020 Simon Glass <sjg@chromium.org>

common: Drop log.h from common header

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# f3998fdc 02-Aug-2019 Simon Glass <sjg@chromium.org>

env: Rename environment.h to env_internal.h

This file contains lots of internal details about the environment. Most
code can include env.h instead, calling the functions there as needed.

Rename this file and add a comment at the top to indicate its internal
nature.

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>
[trini: Fixup apalis-tk1.c]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 4bfd1f5d 01-Aug-2019 Simon Glass <sjg@chromium.org>

env: Move env_init() to env.h

Move env_init() over to the new header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>

# cd121bdb 29-Jun-2019 Frank Wunderlich <frank-w@public-files.de>

env: register erase command

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>

squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 293a172b 18-Jan-2019 Sam Protsenko <semen.protsenko@linaro.org>

env: Fix saving environment to "bad CRC" location

In case when the environment on some location is malformed (CRC isn't
matching), there is a chance we won't be able to save the environment to
that location. For example, consider the case when we only have the
environment on eMMC, but it's zeroed out. In that case, we won't be able
to "env save" to it, because of "bad CRC" error. That's happening
because in env_load() function we consider malformed environment as
incorrect one, and defaulting to the location with highest (0)
priority, which can be different from one we are dealing with right now
(e.g., highest priority can be ENV_FAT on SD card, which is not
inserted, but we want to use ENV_MMC on eMMC, where we were booted
from).

This issue began to reproduce after commit d30ba2315ae3 ("u-boot: remove
driver lookup loop from env_save()") on BeagleBone Black, but that
commit didn't introduce the wrong logic, it just changed the behavior
for default location to use, merely revealing this issue.

To fix that, let's implement next logic in env_load():
1. Try to find out correct environment; if found -- use it
2. If working environment wasn't found, but we found malformed one
(with bad CRC), let's use it for further "env save". But make sure
to use malformed environment location with highest priority.
3. If neither correct nor malformed environment was found, let's
default to environment location with highest priority (0)

Steps to reproduce mentioned issue on BeagleBone Black (fixed in this
patch):

1. Boot from SD card and erase eMMC in U-Boot shell:
=> mmc dev 1
=> mmc erase 0 100000
=> gpt write mmc 1 $partitions
2. Write new SPL and U-Boot to eMMC; the rest of eMMC will stay filled
with zeroes
3. Boot from eMMC; try to do:
=> env save
4. Observe the error (incorrect behavior). Correct behavior: environment
should be stored correctly on eMMC, in spite of it has "bad CRC"

Fixes: d30ba2315ae3 ("u-boot: remove driver lookup loop from env_save()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>

# 9a6a311d 04-Jan-2019 Ye Li <ye.li@nxp.com>

env: sata: Add missed env location for SATA boot

The env location label ENVL_ESATA is missed in location tables, so
when we configure the ENV in SATA, u-boot fails to get correct env
location and cause boot hang in board_f.

Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>

# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>

# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>

# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>

# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>

# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>

# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>

# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c

# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>

# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>

# 13bbfb4a 30-Jul-2018 Sam Protsenko <semen.protsenko@linaro.org>

env: Don't show "Failed" error message

"Failed" error message from env_load() only clutters the log with
unnecessary details, as we already have all needed warnings by that
time. Example:

Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)

Let's only print it in case when DEBUG is defined to keep log clear.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>


# d30ba231 23-Jul-2018 Nicholas Faustini <nicholas.faustini@azcomtech.com>

u-boot: remove driver lookup loop from env_save()

When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.

This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.

The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.

Signed-off-by: Nicholas Faustini <nicholas.faustini@azcomtech.com>
Reviewed-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>


# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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: Tom Rini <trini@konsulko.com>


# 7bcdf195 12-Apr-2018 Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>

env: Relocate env drivers if manual reloc is required

Relocate env drivers if manual relocation is enabled. This
patch fixes the issue of u-boot hang incase if env is
present in any of the flash devices.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>


# b2cdef48 09-Feb-2018 Goldschmidt Simon <sgoldschmidt@de.pepperl-fuchs.com>

env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env
drivers does not really make sense any more because it is
only supported by two drivers (eeprom and nvram).

To restore single character loading for these drivers,
override 'env_get_char_spec'.

Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>


# e1caa584 07-Feb-2018 York Sun <york.sun@nxp.com>

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have the value set before.
In case the value was set before relocation and U-Boot runs from a
NOR flash, this variable wasn't writable. This causes failure when
saving the environment. To save this location, global data must be
used instead.

Signed-off-by: York Sun <york.sun@nxp.com>
CC: Maxime Ripard <maxime.ripard@free-electrons.com>


# 40c08a68 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Mark env_get_location as weak

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 1d446087 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Initialise all the environments

Since we want to have multiple environments, we will need to initialise
all the environments since we don't know at init time what drivers might
fail when calling load.

Let's init all of them, and only consider for further operations the ones
that have not reported any errors at init time.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 7d714a24 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Support multiple environments

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 3574ba01 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make it explicit where we're loading our environment from

Since we can have multiple environments now, it's better to provide a
decent indication on what environments were tried and which were the one to
fail and succeed.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 9efac3c8 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Make the env save message a bit more explicit

Since we'll soon have support for multiple environments, the environment
saving message might end up being printed multiple times if the higher
priority environment cannot be used.

That might confuse the user, so let's make it explicit if the operation
failed or not.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 8a3a7e22 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Pass additional parameters to the env lookup function

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 52746c43 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

env: Rename env_driver_lookup_default and env_get_default_location

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 9c24dfb2 23-Jan-2018 Maxime Ripard <maxime.ripard@free-electrons.com>

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>


# 1087a794 10-Jan-2018 Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the following
configs should be added to the board's default config:

CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
CONFIG_ENV_EXT4_FILE="/uboot.env"
CONFIG_ENV_EXT4_INTERFACE="mmc"

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
[trini: Fix some line over 80 chars issues]
Signed-off-by: Tom Rini <trini@konsulko.com>


# 7b7341d7 10-Oct-2017 Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

fdc7718999 ("board: usb_a9263: Update to support DT and DM")

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>


# 2d7cb5b4 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Replace all open-coded gd->env_valid values with ENV_ flags

Some of these were missed in the conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>


# c55d8b94 20-Aug-2017 Simon Glass <sjg@chromium.org>

env: Allow env_load() to detect errors

Now that we have errors available in the environment driver's load()
method, check the return valid.

Signed-off-by: Simon Glass <sjg@chromium.org>


# eeba55cb 19-Aug-2017 Tom Rini <trini@konsulko.com>

env: Correct case of no sub-init function

With the change to the environment code to remove the common init stage
of pointing to the default environment and setting it as valid, combined
with the change to switch gd->env_valid from 0/1/2 to an enum we now
must set env_valid to one of the enum values rather than an int. And in
this case, not only was setting it to an int wrong, it was now the wrong
value. Finally, in the case of ENV_IS_NOWHERE we must still say that
our envionrment is invalid after init for things to continue to
function.

Fixes: 7938822a6b75 ("env: Drop common init() functions")
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually include changes for env/nowhere.c


# 01510091 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop saveenv() in favour of env_save()

Use the env_save() function directly now that there is only one
implementation of saveenv().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 310fb14b 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_relocate_spec() in favour of env_load()

This is a strange name for a function that loads the environment. There is
now only one implementation of this function, so use the new env_load()
function directly instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# a69d0f60 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_get_char_spec()

We only have a single implementation of this function now and it is called
env_get_char(). Drop the old function and the weak version.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>


# 6eeae424 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop env_init_new()

Now that env_init() is only defined once we can drop the env_init_new()
name and just use env_init().

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# ac358beb 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop the env_name_spec global

Add a name to the driver and use that instead of the global variable
declared by each driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# 7938822a 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Drop common init() functions

Most of the init() implementations just use the default environment.
Adjust env_init_new() to do this automatically, and drop the redundant
code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# e5bce247 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Switch over to use environment location drivers

Move over to use a the master implementation of the location drivers, with
each method calling out to the appropriate driver.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>


# c9d728dd 03-Aug-2017 Simon Glass <sjg@chromium.org>

env: Add a new implementation of environment access

We plan to move to a environment access via drivers for each location
where the environment can be stored. Add an implementation for this. So
far it is not used, but will be pressed into service in a future patch.

Signed-off-by: Simon Glass <sjg@chromium.org>