[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Wolfgang Denk]

In message <46535464.6090206 at freescale.com> you wrote:
> Doesn't anyone have an answer to this question?

Maybe nobody cares? It's an officially unsupported feature anyway.

> Timur Tabi wrote:
> > On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:

Let's put this straight: it is not "a lot of boards", it's just 16
boards - less than 5%:

MPC8313ERDB       MPC8360EMDS       MPC8641HPCN       TQM834x
MPC832XEMDS       MPC8540ADS        PM854             sbc8349
MPC8349EMDS       MPC8540EVAL       PM856             sbc8560
MPC8349ITX        MPC8560ADS        SBC8540           stxgp3

If you look closer, you can see that it's only 83xx,  85xx  and  86xx
systems.  Guess  where  most of the responsible board maintainers are
sitting? And who the responsible custodians are?

> >    #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - 0x1000)
> >    #define CFG_ENV_SIZE		0x2000

Of course this is broken and should always be written as 

	#define CFG_ENV_ADDR (CFG_MONITOR_BASE-CFG_ENV_SECT_SIZE)

instead.

> > This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. 
> > Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will 
> > overwrite the beginning of u-boot.bin whenever someone does a saveenv?

I suggest you raise the  issue  with  the  board  maintainers  and/or
custodians. Maybe you simply remove all this broken ramboot support.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."           - Terry Pratchett, _Witches Abroad_