summaryrefslogtreecommitdiff
path: root/env/env.c
AgeCommit message (Collapse)Author
2019-01-26env: Fix saving environment to "bad CRC" locationSam Protsenko
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-09env: sata: Add missed env location for SATA bootYe Li
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>
2018-08-10env: Don't show "Failed" error messageSam Protsenko
"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-30u-boot: remove driver lookup loop from env_save()Nicholas Faustini
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-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
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-04-16env: Relocate env drivers if manual reloc is requiredSiva Durga Prasad Paladugu
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-02-16env: restore old env_get_char() behaviourGoldschmidt Simon
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-16env: Fix env_load_locationYork Sun
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>
2018-01-27env: Mark env_get_location as weakMaxime Ripard
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-27env: Initialise all the environmentsMaxime Ripard
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-27env: Support multiple environmentsMaxime Ripard
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-27env: Make it explicit where we're loading our environment fromMaxime Ripard
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-27env: Make the env save message a bit more explicitMaxime Ripard
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-27env: Pass additional parameters to the env lookup functionMaxime Ripard
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-27env: Rename env_driver_lookup_default and env_get_default_locationMaxime Ripard
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-27cmd: nvedit: Get rid of the env lookupMaxime Ripard
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>
2018-01-15env: enable accessing the environment in an EXT4 partitionJorge Ramirez-Ortiz
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>
2017-10-16env: Drop CONFIG_ENV_IS_IN_DATAFLASHTuomas Tynkkynen
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>
2017-08-20env: Replace all open-coded gd->env_valid values with ENV_ flagsSimon Glass
Some of these were missed in the conversion. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-08-20env: Allow env_load() to detect errorsSimon Glass
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>
2017-08-20env: Correct case of no sub-init functionTom Rini
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-15env: Drop saveenv() in favour of env_save()Simon Glass
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>
2017-08-15env: Drop env_relocate_spec() in favour of env_load()Simon Glass
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>
2017-08-15env: Drop env_get_char_spec()Simon Glass
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-15env: Drop env_init_new()Simon Glass
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-15env: Drop the env_name_spec globalSimon Glass
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>
2017-08-15env: Drop common init() functionsSimon Glass
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-15env: Switch over to use environment location driversSimon Glass
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>
2017-08-15env: Add a new implementation of environment accessSimon Glass
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>