u-boot.git/env, branch v2020.07-rc2

env/sf.c: honour CONFIG_SPL_SAVEENV

2020-05-08T22:29:11+00:00

Deciding whether to compile the env_sf_save() function based solely on
CONFIG_SPL_BUILD is wrong: For U-Boot proper, it leads to a build
warning in case CONFIG_CMD_SAVEENV=n (because the initialization of
the .save member is guarded by CONFIG_CMD_SAVEENV, while the
env_sf_save() function is built if !CONFIG_SPL_BUILD - and even
without the CONFIG_CMD_SAVEENV guard, the env_save_ptr() macro would
just expand to NULL, with no reference to env_sf_save visible to the
compiler). And for SPL, when one selects CONFIG_SPL_SAVEENV, one
obviously expects to actually be able to save the environment.

The compiler warning can be fixed by using a " ?
env_sf_save : NULL" construction instead of a macro that just eats its
argument and expands to NULL. That way, if  is false,
env_sf_save gets eliminated as dead code, but the compiler still sees
the reference to it.

For , we can use CONFIG_IS_ENABLED(SAVEENV), which is true
precisely:

- For U-Boot proper, when CONFIG_CMD_SAVEENV is set (because
  CONFIG_SAVEENV is a hidden config symbol that gets set if and only
  if CONFIG_CMD_SAVEENV is set).
- For SPL, when CONFIG_SPL_SAVEENV is set.

As a bonus, this also removes quite a few preprocessor conditionals.

This has been run-time tested on a mpc8309-derived board to verify
that saving the environment does indeed work in SPL with these patches
applied.

Signed-off-by: Rasmus Villemoes

env/sf.c: drop private CMD_SAVEENV logic

2020-04-24T14:10:00+00:00

Deciding whether to compile the env_sf_save() function based solely on
CONFIG_SPL_BUILD is wrong: For U-Boot proper, it leads to a build
warning in case CONFIG_CMD_SAVEENV=n (because the env_save_ptr() macro
causes the function to indeed not be referenced anywhere). And for
SPL, when one selects CONFIG_SPL_SAVEENV, one obviously expects to
actually be able to save the environment.

Signed-off-by: Rasmus Villemoes

env/ext4.c: remove CONFIG_CMD_SAVEENV ifdef

2020-04-24T14:10:00+00:00

Removing this ifdef/endif pair yields a "defined but unused warning"
for CONFIG_CMD_SAVEENV=n, but that vanishes if we use the ENV_SAVE_PTR
macro instead. This gives slightly better compile testing, and
moreover, it's possible to have

  CONFIG_CMD_SAVEENV=n
  CONFIG_SPL_SAVEENV=y
  SPL_ENV_IS_IN_EXT4=y

in which case env_ext4_save would erroneously not be compiled in.

Signed-off-by: Rasmus Villemoes

env/fat.c: remove private CMD_SAVEENV logic

2020-04-24T14:10:00+00:00

Always compile the env_fat_save() function, and let
CONFIG_IS_ENABLED(SAVEENV) (via the ENV_SAVE_PTR macro) decide whether
it actually ends up being compiled in.

Signed-off-by: Rasmus Villemoes

env: add SAVEENV as an alias of the CMD_SAVEENV symbol

2020-04-24T14:10:00+00:00

Currently, testing whether to compile in support for saving the
environment is a bit awkward when one needs to take SPL_SAVEENV into
account, and quite a few storage drivers currently do not honour
SPL_SAVEENV.

To make it a bit easier to decide whether environment saving should be
enabled, introduce SAVEENV as an alias for the CMD_SAVEENV
symbol. Then one can simply use

  CONFIG_IS_ENABLED(SAVEENV)

Signed-off-by: Rasmus Villemoes

make env_entry::callback conditional on !CONFIG_SPL_BUILD

2020-04-24T14:09:59+00:00

The callback member of struct env_entry is always NULL for an SPL
build. Removing it thus saves a bit of run-time memory in the
SPL (when CONFIG_SPL_ENV_SUPPORT=y) since struct env_entry is embedded
in struct env_entry_node - i.e. about 2KB for the normal case of
512+change hash table entries.

Two small fixups are needed for this, all other references to the
callback member are already under !CONFIG_SPL_BUILD: Don't initialize
.callback in set_flags() - hsearch_r doesn't use that value
anyway. And make env_callback_init() initialize ->callback to NULL for
a new entry instead of relying on an unused or deleted entry having
NULL in ->callback.

Signed-off-by: Rasmus Villemoes 
Reviewed-by: Simon Glass

env: remove callback.o for an SPL build

2020-04-24T14:09:59+00:00

env.h says this about about callback declarations (U_BOOT_ENV_CALLBACK):

 * For SPL these are silently dropped to reduce code size, since environment
 * callbacks are not supported with SPL.

So env_callback_init() does a lot of work to not find anything in the
guaranteed empty env_clbk list. Drop callback.o entirely from the link
and stub out the only public function defined in callback.o. This cuts
about 600 bytes from the SPL on my ppc build.

Signed-off-by: Rasmus Villemoes 
Reviewed-by: Simon Glass

env: make file-scope env_ptr variables static

2020-04-17T16:29:43+00:00

The combination ENV_IS_IN_NVRAM=y, ENV_IS_IN_REMOTE=y fails to build:

env/remote.o:/mnt/ext4/devel/u-boot/env/remote.c:17: multiple definition of `env_ptr'
env/nvram.o:/mnt/ext4/devel/u-boot/env/nvram.c:41: first defined here

It's not necessarily a meaningful combination, but for build-testing
it's nice to be able to enable most ENV_IS_IN_* at the same time, and
since these env_ptr are not declared anywhere, they really have no
reason to have external linkage.

nand.c and flash.c similarly already define file-scope static env_ptr
variables.

Signed-off-by: Rasmus Villemoes

env: Make mmc as default option for CONFIG_ENV_FAT_INTERFACE

2020-04-06T10:52:45+00:00

All configs are using mmc as default fat interface. That's why make it
default for everybody.
The reason for this patch is to make it default for Xilinx Zynq platform
which is not listed there.

Signed-off-by: Michal Simek

env: Kconfig: Adding default values for Microblaze

2020-04-06T10:51:31+00:00

This patch will add default values for ENV_OFFSET
and ENV_SECT_SIZE for Microblaze.

Signed-off-by: Varalaxmi Bingi 
Signed-off-by: Michal Simek