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
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>
show more ...
|
119c01c2 | 05-Nov-2018 |
Rajesh Bhagat <rajesh.bhagat@nxp.com> |
env: sf: define API to override sf environment address
Defines env_sf_get_env_addr API to override sf environment address, required to support multiple environment.
Signed-off-by: Rajesh Bhagat <ra
env: sf: define API to override sf environment address
Defines env_sf_get_env_addr API to override sf environment address, required to support multiple environment.
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
show more ...
|
474ecd2c | 26-Jun-2018 |
York Sun <york.sun@nxp.com> |
env: Simplify Makefile using $(SPL_TPL_)
Add Kconfig options SPL_ENV_* and TPL_ENV_* and simplify Makefile. This allows SPL/TPL image has different environment setting from full feature U-Boot.
Sig
env: Simplify Makefile using $(SPL_TPL_)
Add Kconfig options SPL_ENV_* and TPL_ENV_* and simplify Makefile. This allows SPL/TPL image has different environment setting from full feature U-Boot.
Signed-off-by: York Sun <york.sun@nxp.com>
show more ...
|
c5d548a9 | 24-Jun-2018 |
Yaniv Levinsky <yaniv.levinsky@compulab.co.il> |
env: common: accept flags on reset to default env
The function set_default_env() sets the hashtable flags for import_r(). Formally set_default_env() doesn't accept flags from its callers. In practic
env: common: accept flags on reset to default env
The function set_default_env() sets the hashtable flags for import_r(). Formally set_default_env() doesn't accept flags from its callers. In practice the caller can (un)set the H_INTERACTIVE flag, but it has to be done using the first character of the function's string argument. Other flags like H_FORCE can't be set by the caller.
Change the function to accept flags argument. The benefits are: 1. The caller will have to explicitly set the H_INTERACTIVE flag, instead of un-setting it using a special char in a string. 2. Add the ability to propagate flags from the caller to himport(), especially the H_FORCE flag from do_env_default() in nvedit.c that currently gets ignored for "env default -a -f" commands. 3. Flags and messages will not be coupled together. A caller will be able to set flags without passing a string and vice versa.
Please note: The propagation of H_FORCE from do_env_default() does not introduce any functional changes, because currently himport_r() is set to destroy the old environment regardless if H_FORCE flag is set or not. More changes are needed to utilize the propagation of H_FORCE.
Signed-off-by: Yaniv Levinsky <yaniv.levinsky@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
show more ...
|
5a04264e | 24-Jun-2018 |
Yaniv Levinsky <yaniv.levinsky@compulab.co.il> |
cmd: nvedit: set H_INTERACTIVE in do_env_default
The function set_default_vars() in common.c adds H_INTERACTIVE to the h_import() flag, but the function has no way of telling if the command actually
cmd: nvedit: set H_INTERACTIVE in do_env_default
The function set_default_vars() in common.c adds H_INTERACTIVE to the h_import() flag, but the function has no way of telling if the command actually was user directed like this flag suggest. The flag should be set by the calling function do_env_default() in nvedit.c instead, where the command is certainty user directed.
Move the H_INTERACTIVE flag from set_default_vars() to do_env_default().
Signed-off-by: Yaniv Levinsky <yaniv.levinsky@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
show more ...
|