[U-Boot] [PATCH] Revert "env_eeprom: Assign default environment during board_init_f"

[Tom Rini <trini@konsulko.com>]

On Tue, Sep 15, 2015 at 11:35:35AM +0200, Ludger Dreier wrote:

> This reverts commit ed6a5d4f880ac248530dbf64683b2257dbe54b64.
> 
> The original patch uses ENV_IS_EMBEDDED to decide if the default
> environment should be used or the one actually read from EEPROM. The
> code in environment.h allows setting of ENV_IS_EMBEDDED only for
> a subset of flash types. EEPROM is not included in that list.
> So basically reading environment from I2C EEPROM is broken now.
> I propose to revert the patch.
> 
> Signed-off-by: Ludger Dreier <ludger.dreier@keymile.com>

OK, so I went and looked at the original patch and thread again[1] and
Michal or Siva, what case was this change fixing exactly because now
that I re-read it all again, and look harder at the code, this doesn't
make sense.  You can't have embedded u-boot + EEPROM.  Was there perhaps
some sort of init ordering issue in a board which did have EEPROM used
as the backing store for env?  I could see a case where perhaps (and
Ludger, can you test this as well please?) the problem is that for
env_eeprom env_init() needs to just default to the built-in (like it's
basically doing today) and env_relocate_spec() needs to do the read,
check which is valid, etc, etc, dance which it is _not_ doing today.

-- 
Tom

[1]:
http://u-boot.denx.narkive.com/sMDi8ur0/patch-env-eeprom-assign-default-environment-during-board-init-f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150915/ddc496d9/attachment.sig>