Merge branch '2019-01-25-master-imports'

- snapdragon 820c improvements
- poplar updates
- DFU + SPL cleanups
- Improve the mediatek mmc driver
- Other minor cleanups / improvements

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 ...

Merge branch '2019-01-08-master-imports'

- stm32f7 GPIO fixes
- SATA env fixes
- More DM migration deadline warnings
- Regression fix for non-DM MMC drivers
- dma_alloc_coherent size fix on ARM.

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 ca

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>

show more ...

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:

Loadi

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>

show more ...

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 locati

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>

show more ...

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

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>

show more ...

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 dev

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>

show more ...

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

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>

show more ...

env: Fix env_load_location

Commit 7d714a24d725 ("env: Support multiple environments") added
static variable env_load_location. When saving environmental
variables, this variable is presumed to have

env: Fix env_load_location

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

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

show more ...

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

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>

show more ...

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 callin

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>

show more ...

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 environme

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>

show more ...

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

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>

show more ...

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
pri

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>

show more ...

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 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>

show more ...

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 e

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>

show more ...

cmd: nvedit: Get rid of the env lookup

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's abou

cmd: nvedit: Get rid of the env lookup

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

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

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

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

show more ...

env: enable accessing the environment in an EXT4 partition

For example to store the environment in a file named "/uboot.env" in MMC
"0", where partition "1" contains the EXT4 filesystem, the followi

env: enable accessing the environment in an EXT4 partition

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

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

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

show more ...

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

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

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@ik

env: Drop CONFIG_ENV_IS_IN_DATAFLASH

Last user of this option went away in commit:

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

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

show more ...

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>

env: Allow env_load() to detect errors

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

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

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 ch

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

show more ...

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

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

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

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

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

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

show more ...

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

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

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

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

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

show more ...