In flash vs compiled environment for omap, rasp-pi, socfpga

[Trent Piepho]

On Thu, 2015-10-22 at 09:31 +0200, Sascha Hauer wrote:
> On Wed, Oct 21, 2015 at 11:54:23PM +0000, Trent Piepho wrote:
> > A survey of the defconfigs shows that 25 do not have
> > DEFAULT_ENVIRONMENT.  Of these 14 are omap, socfpga, imx, or at91
> > xloaders.  Of the remaining eleven, 5 have env commands enabled, 3 have
> > selected the simple shell which turns on environment variables, and the
> > remaining 3 get the HUSH shell by default which also has environment
> > variables.
> 
> Environment variables and the thing called "the environment" are
> different things and do not depend on each other. Environment variables
> are the variables in the shell (var=10...), getenv/setenv and stuff.
> This has nothing to do with the saveable files we are talking about
> here. Having one enabled without the other is perfectly valid.

This would be ENVIRONMENT_VARIABLES enabled but ENV_HANDLING not.  Which
does seem to be perfectly valid.  If you have ENV_HANDLING but neither a
compiled in env nor a in flash env, then you get an error when booting.

It also appears that if you have COMMAND_SUPPORT enabled, but do not
have an env (compiled or flash), then you get errors from startup.c when
it tries to read /env/bin/init.  And it won't run barebox_main in this
case.  So I think if you had an xloader and turned on command support it
wouldn't boot properly, since it would error out because of no env and
not run the xload main.

But I don't really care about that.  What I'm interested in is having a
flash env but no compiled in env.  It looks like there is a mistake in
the omap & socfpga code that uses the config option for the latter to
control the former.

If I just remove DEFAULT_ENVIRONMENT from controlling the flash env code
(and I don't see any other boards with a config option to control their
in flash env code), then some omap/socfpga boards will gain an in flash
env they don't have now.  Most of these are xloader configs.  So maybe
the flash env code should depend on !XLOADER?

If I do that, then only three configs gain in flash env that don't have
it, omap3430_sdp3430_per_uart, omap3530_beagle_per_uart, and omap3_evm.

The first two are odd ones and I'm not sure if they are even supposed to
work.  The last one seems like it might be broken.  It has
COMMAND_SUPPORT enabled but no env, which gives that error from
common/startup.c I mentioned above.

Another option would be make the in flash env code depend on
ENV_HANDLING.  That will not change any boards, as no boards without the
in flash env want ENV_HANDLING.

And a third option would be to add a new config just for in flash env.
Which could be set to depend on ENV_HANDLING.  That would allow someone
to create a omap/socfpga board that does have ENV_HANDLING, but turns
off the generic in flash env support (file in FAT partition) and uses
something else that's board specific.