- Ensure that everyone setting mtdids= and mtdparts= is doing so via the
  CONFIG options.
- If the CONFIG options are set, ensure that the default environment
  sets mtdparts / mtdids.

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

The "autoload" environment variable is always checked with env_get_yesno
as it can be set to any form of no.  The default behavior of
env_get_yesno is to return -1 on variables that are not set, which acts
as true in general (we test for non-zero return).  To convert
CONFIG_SYS_AUTOLOAD to Kconfig, given that it was almost always used to
set autoload to no, first rename to CONFIG_SYS_DISABLE_AUTOLOAD for
consistency sake.  Then, make it so that if enabled we set autoload=0 in
the default environment.  Migrate all platforms which set
CONFIG_SYS_AUTOLOAD to non-true or that set autoload to false in their
default environment to using CONFIG_SYS_DISABLE_AUTOLOAD

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

Largely, the use of CONFIG_EXTRA_ENV_SETTINGS can be migrated directly
to come from CONFIG_EXTRA_ENV_TEXT.  The biggest case that cannot easily
be migrated is distro_bootcmd support.  Rather than block migration on
this, remove the #error here so that we can being moving forward.

Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_BOOTFILE

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

This converts the following to Kconfig:
   CONFIG_USE_BOOTCOMMAND
   CONFIG_BOOTCOMMAND
   CONFIG_RAMBOOTCOMMAND
   CONFIG_NFSBOOTCOMMAND

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

At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board/<vendor>
directory, typically called <board>.env and controlled by the
CONFIG_ENV_SOURCE_FILE option.

The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example.

In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.
This uses the C preprocessor, means that comments can be included in the
environment using /* ... */

Also support += to allow variables to be appended to. This is needed when
using the preprocessor.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Marek Behún <marek.behun@nic.cz>

Check sizeof(default_environment) against ENV_SIZE in a static_assert()
instead of runtime.
Only check if !USE_HOSTCC (for in fw_env tool ENV_SIZE expands to a
variable, and cannot be checked statically) nad
!DEFAULT_ENV_INSTANCE_EMBEDDED, for in that case the default_environment
variable is not set.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

Sometimes we use uchar and sometimes char for the default environment
array. By always using char, we can get rid of some explicit casts.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>

- In most of the codebase, we reference CONFIG_SYS_LOAD_ADDR and not
  CONFIG_LOADADDR.
- Generally, CONFIG_SYS_LOADADDR is set to CONFIG_LOADADDR and then as
  noted, we use CONFIG_SYS_LOADADDR.

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

It can be useful to use the same U-Boot binary for multiple purposes,
say the normal one, one for developers that allow breaking into the
U-Boot shell, and one for use during bootstrapping which runs a
special-purpose bootcmd. Or one can have several board variants that
can share almost all boot logic, but just needs a few tweaks in the
variables used by the boot script.

To that end, allow the control dtb to contain a /config/enviroment
node (or whatever one puts in fdt_env_path variable), whose
property/value pairs are used to update the run-time environment after
it has been loaded from its persistent location.

The indirection via fdt_env_path is for maximum flexibility - for
example, should the user wish (or board logic dictate) that the values
in the DTB should no longer be applied, one simply needs to delete the
fdt_env_path variable; that can even be done automatically by
including a

  fdt_env_path = "";

property in the DTB node.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>