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.