[U-Boot] Remove global variable env_t *env_ptr ?

[Joakim Tjernlund <Joakim.Tjernlund@infinera.com>]

On Tue, 2017-04-04 at 13:27 +0200, Wolfgang Denk wrote:
> Dear Joakim,
> 
> In message <1491302640.30240.1.camel@infinera.com> you wrote:
> > 
> > > That is my exact question - when would this happen?  Flash sectors
> > > do now wander around in memory or change size :-)
> > 
> > No, but they happens when you are forced to update you HW with new type of flashes
> > with different layout so you have to move where the environment is stored.
> > Sure, this can be fixed by having two different u-boot images but that will
> > in our case be just painful to carry around an extra u-boot img, then in field
> > devise a method to chose the right img. for what looks like the same HW but the flash.
> 
> I see. Well, this obviously means that you are _not_ using an
> embedded environment, as otherwise the linker generated image would
> be wrong for the "other" type of flash chips - which means, the
> environment is somewhare outside, separate from the U-Boot image.

Right. The env. is on separate sectors not in u-boot's own space.

> 
> So you have old hardware, running old U-Boot, which does not support
> the new flash.  For this, you need a new U-Boot, which then shall
> support both the old and the new flash, right?  But why can you then
> not simply come up with a new flash layout, which is compatoble with
> the old and new flashes, so it can use a common configuration,
> without code changes?

Because the old flash has its env. in "small" sectors which does
not exist on new flash so the layout on the new flash has both different env.
address as well as a bigger env. sector size. I cannot move the old
env. either as there is no free space for that(the rest of the flash is a JFFS2 FS)

> 
> I'm aware that embedded environment is not used very often these
> days any more, as is parallel NOR flash, but changes in this are
> have caused trouble more than once in the past, so I am not
> convinced that it's wise to touch such ancient, "stable" code for
> an exotic feature that probably nobody else will ever need?

Again, I don't think I am changing much(if anything) for your embedded case.
Please read the WIP patch I sent earlier and perhaps you can point me to
a potential problem area?

Not sure about "nobody else will ever need" as Micron are terminating the
Intel/cmdset0001 flashes(don't know if this applies to all Intel chips though)
and we have to swap to AMD/cmd0002, we are just early with this change. 

 Jocke