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>

If one defines HUSH_MODERN_PARSER, it is then possible to use modern parser with:
=> cli get
old
=> cli set modern
=> cli get
modern

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>

For the moment, the menu contains only entry: HUSH_OLD_PARSER which is the
default.
The goal is to prepare the field to add a new hush parser which guarantees
actual behavior is still correct.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>

The interactive portion of our non-HUSH 'simple' parser is guarded by
CONFIG_CMDLINE already.  Much of the code behind this simple parser is
also used as "input" parser, such as from menu interfaces and so forth
and not strictly command line input.  To support this, always build the
assorted cli object files, but guard the interactive portions of
cli_simple.c with a CMDLINE check.

Signed-off-by: Tom Rini <trini@konsulko.com>

In order to be able to disable all commands we need to construct our
version string in a common file, and have the version command reference
that string, like the other users of it do.  Create common/version.c
with just the strings.

Signed-off-by: Tom Rini <trini@konsulko.com>

Use the new SPL/TPL/VPL_SYS_MALLOC_F symbols to determine whether the
malloc pool exists.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>

This relates to booting, so move it there. Create a new Kconfig menu for
things related to devicetree fixup.

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

This relates to booting since it fixes up the devicetree for the OS. Move
it into the boot/ directory.

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

This relates to graphics which is only active when CONFIG_VIDEO is
enabled. Move it into that directory.

For most boards there is no harm in compiling it always, since it if not
used it will be dropped by the linker. But for the EFI app this is not
the case, so retain use of the BMP Kconfig.

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

CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN is defined as hex. If set to zero
manually, .config contains '0x0' and not '0' as value.

The default value for CONFIG_SPL_SYS_MALLOC_F_LEN should not be set to 0
but to 0x0 if CONFIG_SPL_FRAMEWORK=n to match a manually set value.

Fixes: c0126bd862a0 ("spl: Support bootstage, log, hash and early malloc in TPL")
Fixes: b61694705217 ("SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without SPL_FRAMEWORK by default")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>