Add support for VPL, a new phase of U-Boot. This runs after TPL. It is
responsible for selecting which SPL binary to run, based on a
verified-boot process.

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

At present if an optional Kconfig value needs to be used it must be
bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE
	bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR
	hex "Address of the wibble"
	depends on WIBBLE

then the following code must be used:

 #ifdef CONFIG_WIBBLE
 static void handle_wibble(void)
 {
 	int val = CONFIG_WIBBLE_ADDR;

	...
 }
 #endif

 static void init_machine()
 {
 ...
 #ifdef CONFIG_WIBBLE
	handle_wibble();
 #endif
 }

Add a new IF_ENABLED_INT() to help with this. So now it is possible to
write, without #ifdefs:

 static void handle_wibble(void)
 {
        int val = IF_ENABLED_INT(CONFIG_WIBBLE, CONFIG_WIBBLE_ADDR);

	...
 }

 static void init_machine()
 {
 ...
 if (IS_ENABLED(CONFIG_WIBBLE))
	handle_wibble();
 }

The value will be CONFIG_WIBBLE_ADDR if CONFIG_WIBBLE is defined and will
produce a build error if not.. This allows us to reduce the use of #ifdef
in the code, ensuring that the compiler still checks the code even if it
is not ultimately used for a particular build.

Add a CONFIG_IF_ENABLED_INT() version as well.

If an attempt is made to use a value that does not exist (i.e. when the
conditional is not enabled), an error about a non-existing function is
generated, e.g.:

common/bloblist.c:447: undefined reference to `invalid_use_of_IF_ENABLED_INT'

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

The config_enabled() macro currently uses 0 as the default value. Update
it to allow any value, so we can pass it something else, such as a
non-existent function, to produce a build error if it is not defined.

Also tidy up the code style for IS_ENABLED() and drop the unnecessary
brackets (the value is a simple 0 or 1).

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

At present we must separately test for the host build for many options,
since we force them to be enabled. For example, CONFIG_FIT is always
enabled in the host tools, even if CONFIG_FIT is not enabled by the
board itself.

It would be more convenient if we could use, for example,
CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
host. Add support for this.

With this and the tools_build() function, we should be able to remove all
the #ifdefs currently needed in code that is build by tools and targets.

This will be even nicer when we move to using CONFIG(xxx) everywhere,
since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go away.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> # b4f73886
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of

  CONFIG_IS_ENABLED(FOO)

expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form

  CONFIG_IS_ENABLED(FOO, (something))

which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines

  #if CONFIG_IS_ENABLED(FOO)
  something
  #endif

The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.

A third variant is also introduced,

  CONFIG_IS_ENABLED(FOO, (xxx), (yyy))

which corresponds to

  #if CONFIG_IS_ENABLED(FOO)
  xxx
  #else
  yyy
  #endif

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.

While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.

This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

This patch adds some commit info for CONFIG_IS_ENABLED(FOO) when used in
TPL context.

Signed-off-by: Lukasz Majewski <lukma@denx.de>

Even though there's now a TPL_DM configuration option, the spl logic
still checks for SPL_DM and thus does not pick up the proper config
option.

This introduces the use of CONFIG_IS_ENABLED(DM) in spl.c to always
pick up the desired configuration option instead of having a
hard-coded check for the SPL variant.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

The previous commit introduced a useful macro used in makefiles,
in order to reference to different variables (CONFIG_... or
CONFIG_SPL_...) depending on the build context.

Per-image config option control is a PITA in C sources, too.
Here are some macros useful in C/CPP expressions.

CONFIG_IS_ENABLED(FOO) can be used as a shorthand for

  (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FOO)) || \
   (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_FOO))

For example, it is useful to describe C code as follows,

  #if CONFIG_IS_ENABLED(OF_CONTROL)
      (device tree code)
  #else
      (board file code)
  #endif

The ifdef conditional above is switched by CONFIG_OF_CONTROL during
the U-Boot proper building (CONFIG_SPL_BUILD is not defined), and by
CONFIG_SPL_OF_CONTROL during SPL building (CONFIG_SPL_BUILD is
defined).

The macro can be used in C context as well, so you can also write the
equivalent code as follows:

  if (CONFIG_IS_ENABLED(OF_CONTROL)) {
      (device tree code)
  } else {
      (board file code)
  }

Another useful macro is CONFIG_VALUE().
CONFIG_VALUE(FOO) is expanded into CONFIG_FOO if CONFIG_SPL_BUILD is
undefined, and into CONFIG_SPL_FOO if CONFIG_SPL_BUILD is defined.

You can write as follows:

  text_base = CONFIG_VALUE(TEXT_BASE);

instead of:

  #ifdef CONFIG_SPL_BUILD
      text_base = CONFIG_SPL_TEXT_BASE;
  #else
      text_base = CONFIG_TEXT_BASE;
  #endif

This commit also adds slight hacking on fixdep so that it can
output a correct list of fixed dependencies.

If the fixdep finds CONFIG_IS_ENABLED(FOO) in a source file,
we want
    $(wildcard include/config/foo.h)
in the U-boot proper building context, while we want
    $(wildcard include/config/spl/foo.h)
in the SPL build context.

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