Since we have global messages to indicate what's going on, the custom
messages in the environment drivers only make the output less readable.

Make MMC play a little nicer by removing all the extra \n and formatting
that is redundant with the global output.
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

Since we have global messages to indicate what's going on, the custom
messages in the environment drivers only make the output less readable.

Make FAT play a little nicer by removing all the extra \n and formatting
that is redundant with the global output.
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

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: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

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: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

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: NMaxime Ripard <maxime.ripard@free-electrons.com>

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: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

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: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

Now that we have and use wait_for_bit_le32() available, the callers of
cm_write_with_phase() should not be casting values to u32 and instead we
expect a const void *, so provide that directly.

Fixes: 48263504 ("wait_bit: use wait_for_bit_le32 and remove wait_for_bit")
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NTom Rini <trini@konsulko.com>

Add allwinner,sun50i-h5-pinctrl compatible for H5 boards.
Signed-off-by: NChris Blake <chrisrblake93@gmail.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>
[jagan: remove external link and format commit message]
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>

The MMC environment offset is getting very close to the end of the U-Boot
binary now. Since we want to make sure this will not overflow, add a size
limit in the board for arm64. arm32 has already that limit enforced in our
custom image generation.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The make macro to check if the binary exceeds the board size limit is not
called. Make sure that is the case.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

fdt overlay support is useful for all sunxi boards, enable per default
and remove it from sunxi defconfigs.
Signed-off-by: NAndre Heider <a.heider@gmail.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this option that is not critical until we can adress the issue
properly.
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Reviewed-by: NAnatolij Gustschin <agust@denx.de>
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Reviewed-by: NAnatolij Gustschin <agust@denx.de>
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

The DFU code relies on the HASH config option. Make sure it is always there
by selecting it.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

Add option to set spi controller clock frequency via device tree
using standard clock bindings.

Define dw_spi_get_clk function as 'weak' as some targets
(like SOCFPGA_GEN5 and SOCFPGA_ARRIA10) don't use standard clock API
and implement dw_spi_get_clk their own way in their clock manager.

Get rid of clock_manager.h include as we don't use
cm_get_spi_controller_clk_hz function anymore. (we use redefined
dw_spi_get_clk in SOCFPGA clock managers instead)
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

Implement dw_spi_get_clk function to override its weak
implementation in designware_spi.c driver.

We need this change to get rid of cm_get_spi_controller_clk_hz
function and clock_manager.h include in designware_spi.c driver.
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>

This prevents the following ENOMEM:
Error binding driver 'bmips_cpu': -12
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>

When flashing U-Boot on a Boston board using Xilinx Vivado tools, the
final 0x00 byte which ends the .relocs section seems to be skipped &
left in flash as 0xff unless the data contained in the .mcs is padded
out to a 16 byte boundary. Without our final zero byte relocation will
fail with an error about a spurious reloc:

Avoid this problem by padding out the data in the .mcs file to a 16 byte
boundary using srec_cat's -range-pad functionality.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>

Poll for broken card detection case instead of return
no card detected.
Signed-off-by: NJun Nie <jun.nie@linaro.org>

When clock is enabling, it's assigned to 0 as mmc->clock.
Then it can't initialize any card.
Fix to assign to correct clock value as mmc->cfg->f_min or f_max.

Fixes: 9546eb92 ("mmc: fix the wrong disabling clock")
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NGuillaume GARDET <guillaume.gardet@free.fr>
Tested-by: NAnand Moon <linux.amoon@gmail.com>
Tested-by: NStephen Warren <swarren@nvidia.com>

Enable the CONFIG_CMD_REGULATOR and CONFIG_DM_REGULATOR_S2MPS11.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NAnand Moon <linux.amoon@gmail.com>