With the relatively new button API in U-Boot, it's now much easier to
model the common usecase of mapping arbitrary actions to different
buttons during boot - for example entering fastboot mode, setting some
additional kernel cmdline arguments, or booting with a custom recovery
ramdisk, to name a few.

Historically, this functionality has been implemented in board code,
making it fixed for a given U-Boot binary and requiring the code be
duplicated and modified for every board.

Implement a generic abstraction to run an arbitrary command during boot
when a specific button is pressed. The button -> command mapping is
configured via environment variables with the following format:

  button_cmd_N_name=<button label>
  button_cmd_N=<command to run>

Where N is the mapping number starting from 0. For example:

  button_cmd_0_name=vol_down
  button_cmd_0=fastboot usb 0

This will cause the device to enter fastboot mode if volume down is held
during boot.

After we enter the cli loop the button commands are no longer valid,
this allows the buttons to additionally be used for navigating a boot
menu.

Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra30
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

We need BOOTSTD_DEFAULT when BOOTSTD_FULL is selected.

Signed-off-by: Shantur Rathore <i@shantur.com>

ret is assigned a value 0 which is never used but
is immediately overwritten in the next statement.

Addresses-Coverity-ID: 453304 ("Unused value")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The 'return 0;' statement is not reachable. Remove it.
'else' is superfluous after an if statement with return.

Addresses-Coverity-ID: 352451 ("Logically dead code")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Sometimes, when only one bootdev is available, and it fails to probe, we
end up in an infinite loop calling probe() on the same device over and
over. With only debug level log output.

Break the loop if we fail to probe the same device twice in a row, and
promote the probe failure message to log_warning().

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>

At this point, EFI boot manager interfaces is fully independent from
bootefi command. So just rename the configuration parameter.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Some code moved from cmd/bootefi.c is actually necessary only for "bootefi
<addr>" command (starting an image manually loaded by a user using U-Boot
load commands or other methods (like JTAG debugger).

The code will never been opted out as unused code by a compiler which
doesn't know how EFI boot manager is implemented. So introduce a new
configuration, CONFIG_EFI_BINARY_EXEC, to enforce them opted out
explicitly.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

ab_control_store() can return an error if writing to disk fails.
In this case, we have to pass the error code to the caller.

Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Building sandbox_defconfig with

    CONFIG_CMD_CEDIT=y
    CONFIG_EXPO=n

fails with

    cmd/cedit.c:258:(.text.do_cedit_run+0x4c):
    undefined reference to `expo_apply_theme

Fix the dependencies.

Fixes: a0874dc4ac71 ("expo: Add a configuration editor")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Sometimes the kernel is built as an EFI application rather than a
binary. We still want to support compression for this case.

For arm64 the entry point is set later in the bootm_load_os() function,
since these images are typically relocated due to the 2MB-alignment
requirement of arm64 images. But since the EFI image is not in the same
format, we need to update the entry point earlier.

Set the entry point always, for kernel_noload to resolve this problem.
It should be harmless to do this always.

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