mirrors/u-boot
0
0
Fork 0
mirror of https://github.com/u-boot/u-boot.git synced 2024-12-01 00:23:29 +08:00
Code Issues Packages Projects Releases Wiki Activity
3a7d55716d
u-boot/env/env.c

313 lines
6.5 KiB
C
Raw Normal View History

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>
2018-05-07 05:58:06 +08:00
// SPDX-License-Identifier: GPL-2.0+
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>
2017-08-04 02:22:00 +08:00
/*
* Copyright (C) 2017 Google, Inc
* Written by Simon Glass <sjg@chromium.org>
*/
#include <common.h>
#include <environment.h>
DECLARE_GLOBAL_DATA_PTR;
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>
2018-04-13 13:57:21 +08:00
#if defined(CONFIG_NEEDS_MANUAL_RELOC)
void env_fix_drivers(void)
{
struct env_driver *drv;
const int n_ents = ll_entry_count(struct env_driver, env_driver);
struct env_driver *entry;
drv = ll_entry_start(struct env_driver, env_driver);
for (entry = drv; entry != drv + n_ents; entry++) {
if (entry->name)
entry->name += gd->reloc_off;
if (entry->load)
entry->load += gd->reloc_off;
if (entry->save)
entry->save += gd->reloc_off;
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>
2019-06-29 17:36:19 +08:00
if (entry->erase)
entry->erase += gd->reloc_off;
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>
2018-04-13 13:57:21 +08:00
if (entry->init)
entry->init += gd->reloc_off;
}
}
#endif
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>
2018-01-24 04:16:51 +08:00
static struct env_driver *_env_driver_lookup(enum env_location loc)
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>
2017-08-04 02:22:00 +08:00
{
struct env_driver *drv;
const int n_ents = ll_entry_count(struct env_driver, env_driver);
struct env_driver *entry;
drv = ll_entry_start(struct env_driver, env_driver);
for (entry = drv; entry != drv + n_ents; entry++) {
if (loc == entry->location)
return entry;
}
/* Not found */
return NULL;
}
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>
2018-01-24 04:16:58 +08:00
static enum env_location env_locations[] = {
#ifdef CONFIG_ENV_IS_IN_EEPROM
ENVL_EEPROM,
#endif
#ifdef CONFIG_ENV_IS_IN_EXT4
ENVL_EXT4,
#endif
#ifdef CONFIG_ENV_IS_IN_FAT
ENVL_FAT,
#endif
#ifdef CONFIG_ENV_IS_IN_FLASH
ENVL_FLASH,
#endif
#ifdef CONFIG_ENV_IS_IN_MMC
ENVL_MMC,
#endif
#ifdef CONFIG_ENV_IS_IN_NAND
ENVL_NAND,
#endif
#ifdef CONFIG_ENV_IS_IN_NVRAM
ENVL_NVRAM,
#endif
#ifdef CONFIG_ENV_IS_IN_REMOTE
ENVL_REMOTE,
#endif
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>
2019-01-04 17:34:24 +08:00
#ifdef CONFIG_ENV_IS_IN_SATA
ENVL_ESATA,
#endif
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>
2018-01-24 04:16:58 +08:00
#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
ENVL_SPI_FLASH,
#endif
#ifdef CONFIG_ENV_IS_IN_UBI
ENVL_UBI,
#endif
#ifdef CONFIG_ENV_IS_NOWHERE
ENVL_NOWHERE,
#endif
};
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>
2018-01-24 04:16:59 +08:00
static bool env_has_inited(enum env_location location)
{
return gd->env_has_init & BIT(location);
}
static void env_set_inited(enum env_location location)
{
/*
* We're using a 32-bits bitmask stored in gd (env_has_init)
* using the above enum value as the bit index. We need to
* make sure that we're not overflowing it.
*/
BUILD_BUG_ON(ARRAY_SIZE(env_locations) > BITS_PER_LONG);
gd->env_has_init |= BIT(location);
}
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>
2018-01-24 04:16:52 +08:00
/**
* env_get_location() - Returns the best env location for a board
* @op: operations performed on the environment
* @prio: priority between the multiple environments, 0 being the
* highest priority
*
* This will return the preferred environment for the given priority.
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>
2018-01-24 04:17:02 +08:00
* This is overridable by boards if they need to.
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>
2018-01-24 04:16:52 +08:00
*
* All implementations are free to use the operation, the priority and
* any other data relevant to their choice, but must take into account
* the fact that the lowest prority (0) is the most important location
* in the system. The following locations should be returned by order
* of descending priorities, from the highest to the lowest priority.
*
* Returns:
* an enum env_location value on success, a negative error code otherwise
*/
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>
2018-01-24 04:17:02 +08:00
__weak enum env_location env_get_location(enum env_operation op, int prio)
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>
2017-08-04 02:22:00 +08:00
{
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>
2018-07-23 16:01:07 +08:00
if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
gd->env_load_prio = prio;
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>
2018-01-24 04:16:52 +08:00
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>
2018-07-23 16:01:07 +08:00
return env_locations[prio];
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>
2017-08-04 02:22:00 +08:00
}
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>
2018-01-24 04:16:52 +08:00
/**
* env_driver_lookup() - Finds the most suited environment location
* @op: operations performed on the environment
* @prio: priority between the multiple environments, 0 being the
* highest priority
*
* This will try to find the available environment with the highest
* priority in the system.
*
* Returns:
* NULL on error, a pointer to a struct env_driver otherwise
*/
static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
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>
2017-08-04 02:22:00 +08:00
{
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>
2018-01-24 04:16:52 +08:00
enum env_location loc = env_get_location(op, prio);
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>
2017-08-04 02:22:00 +08:00
struct env_driver *drv;
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>
2018-01-24 04:16:52 +08:00
if (loc == ENVL_UNKNOWN)
return NULL;
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>
2018-01-24 04:16:51 +08:00
drv = _env_driver_lookup(loc);
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>
2017-08-04 02:22:00 +08:00
if (!drv) {
debug("%s: No environment driver for location %d\n", __func__,
loc);
return NULL;
}
return drv;
}
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>
2018-02-10 04:23:17 +08:00
__weak int env_get_char_spec(int index)
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>
2017-08-04 02:22:00 +08:00
{
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>
2018-02-10 04:23:17 +08:00
return *(uchar *)(gd->env_addr + index);
}
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>
2017-08-04 02:22:00 +08:00
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>
2018-02-10 04:23:17 +08:00
int env_get_char(int index)
{
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>
2017-08-20 18:45:15 +08:00
if (gd->env_valid == ENV_INVALID)
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>
2017-08-04 02:22:06 +08:00
return default_environment[index];
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>
2018-02-10 04:23:17 +08:00
else
return env_get_char_spec(index);
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>
2017-08-04 02:22:00 +08:00
}
int env_load(void)
{
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>
2018-01-24 04:16:52 +08:00
struct env_driver *drv;
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>
2019-01-19 03:19:04 +08:00
int best_prio = -1;
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>
2018-01-24 04:16:52 +08:00
int prio;
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>
2017-08-04 02:22:00 +08:00
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>
2018-01-24 04:16:52 +08:00
for (prio = 0; (drv = env_driver_lookup(ENVOP_LOAD, prio)); prio++) {
int ret;
if (!drv->load)
continue;
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>
2018-01-24 04:16:59 +08:00
if (!env_has_inited(drv->location))
continue;
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>
2018-01-24 04:16:54 +08:00
printf("Loading Environment from %s... ", drv->name);
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>
2018-07-31 00:19:26 +08:00
/*
* In error case, the error message must be printed during
* drv->load() in some underlying API, and it must be exactly
* one message.
*/
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>
2018-01-24 04:16:52 +08:00
ret = drv->load();
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>
2019-01-19 03:19:04 +08:00
if (!ret) {
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>
2018-01-24 04:16:54 +08:00
printf("OK\n");
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>
2018-01-24 04:16:52 +08:00
return 0;
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>
2019-01-19 03:19:04 +08:00
} else if (ret == -ENOMSG) {
/* Handle "bad CRC" case */
if (best_prio == -1)
best_prio = prio;
} else {
debug("Failed (%d)\n", ret);
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>
2018-07-31 00:19:26 +08:00
}
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>
2017-08-04 02:22:00 +08:00
}
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>
2018-07-23 16:01:07 +08:00
/*
* In case of invalid environment, we set the 'default' env location
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>
2019-01-19 03:19:04 +08:00
* to the best choice, i.e.:
* 1. Environment location with bad CRC, if such location was found
* 2. Otherwise use the location with highest priority
*
* This way, next calls to env_save() will restore the environment
* at the right place.
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>
2018-07-23 16:01:07 +08:00
*/
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>
2019-01-19 03:19:04 +08:00
if (best_prio >= 0)
debug("Selecting environment with bad CRC\n");
else
best_prio = 0;
env_get_location(ENVOP_LOAD, best_prio);
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>
2018-07-23 16:01:07 +08:00
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>
2018-01-24 04:16:52 +08:00
return -ENODEV;
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>
2017-08-04 02:22:00 +08:00
}
int env_save(void)
{
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>
2018-01-24 04:16:52 +08:00
struct env_driver *drv;
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>
2017-08-04 02:22:00 +08:00
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>
2018-07-23 16:01:07 +08:00
drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
if (drv) {
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>
2018-01-24 04:16:52 +08:00
int ret;
if (!drv->save)
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>
2018-07-23 16:01:07 +08:00
return -ENODEV;
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>
2018-01-24 04:16:52 +08:00
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>
2018-01-24 04:16:59 +08:00
if (!env_has_inited(drv->location))
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>
2018-07-23 16:01:07 +08:00
return -ENODEV;
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>
2018-01-24 04:16:59 +08:00
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>
2018-01-24 04:16:53 +08:00
printf("Saving Environment to %s... ", drv->name);
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>
2018-01-24 04:16:52 +08:00
ret = drv->save();
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>
2018-01-24 04:16:54 +08:00
if (ret)
printf("Failed (%d)\n", ret);
else
printf("OK\n");
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>
2018-01-24 04:16:52 +08:00
if (!ret)
return 0;
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>
2017-08-04 02:22:00 +08:00
}
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>
2018-01-24 04:16:52 +08:00
return -ENODEV;
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>
2017-08-04 02:22:00 +08:00
}
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>
2019-06-29 17:36:19 +08:00
int env_erase(void)
{
struct env_driver *drv;
drv = env_driver_lookup(ENVOP_ERASE, gd->env_load_prio);
if (drv) {
int ret;
if (!drv->erase)
return -ENODEV;
if (!env_has_inited(drv->location))
return -ENODEV;
printf("Erasing Environment on %s... ", drv->name);
ret = drv->erase();
if (ret)
printf("Failed (%d)\n", ret);
else
printf("OK\n");
if (!ret)
return 0;
}
return -ENODEV;
}
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>
2017-08-04 02:22:05 +08:00
int env_init(void)
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>
2017-08-04 02:22:00 +08:00
{
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>
2018-01-24 04:16:52 +08:00
struct env_driver *drv;
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>
2017-08-04 02:22:02 +08:00
int ret = -ENOENT;
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>
2018-01-24 04:16:52 +08:00
int prio;
for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
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>
2018-01-24 04:16:59 +08:00
if (!drv->init || !(ret = drv->init()))
env_set_inited(drv->location);
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>
2018-01-24 04:16:52 +08:00
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>
2018-01-24 04:16:59 +08:00
debug("%s: Environment %s init done (ret=%d)\n", __func__,
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>
2018-01-24 04:16:52 +08:00
drv->name, ret);
}
if (!prio)
return -ENODEV;
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>
2017-08-04 02:22:02 +08:00
if (ret == -ENOENT) {
gd->env_addr = (ulong)&default_environment[0];
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
2017-08-20 10:27:57 +08:00
gd->env_valid = ENV_VALID;
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>
2017-08-04 02:22:02 +08:00
return 0;
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>
2017-08-04 02:22:00 +08:00
}
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>
2018-01-24 04:16:52 +08:00
return ret;
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>
2017-08-04 02:22:00 +08:00
}
Reference in New Issue Copy Permalink