u-boot.git/env/env.c, branch v2018.03

env: restore old env_get_char() behaviour

2018-02-16T16:12:42+00:00

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 
Acked-by: Maxime Ripard

env: Fix env_load_location

2018-02-16T16:12:41+00:00

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 
CC: Maxime Ripard

env: Mark env_get_location as weak

2018-01-27T14:23:22+00:00

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

Reviewed-by: Andre Przywara 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Simon Glass 
Signed-off-by: Maxime Ripard

env: Initialise all the environments

2018-01-27T14:21:57+00:00

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 
Signed-off-by: Maxime Ripard

env: Support multiple environments

2018-01-27T14:21:57+00:00

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 
Reviewed-by: Simon Glass 
Signed-off-by: Maxime Ripard

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

2018-01-27T14:19:11+00:00

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 
Signed-off-by: Maxime Ripard

env: Make the env save message a bit more explicit

2018-01-27T14:19:11+00:00

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 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Simon Glass 
Signed-off-by: Maxime Ripard

env: Pass additional parameters to the env lookup function

2018-01-27T14:19:11+00:00

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

env: Rename env_driver_lookup_default and env_get_default_location

2018-01-27T14:19:11+00:00

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 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Simon Glass 
Signed-off-by: Maxime Ripard

cmd: nvedit: Get rid of the env lookup

2018-01-27T14:19:11+00:00

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 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Simon Glass 
Signed-off-by: Maxime Ripard