[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

[Wolfgang Denk]

Dear Haavard & Becky,

In message <20090830173640.2af9ce3c at siona> you wrote:
>
> >  The only way for that to work
> > is when VA=PA (or, depending on what you were doing with the address,

Well, VA==PA is the default setting for U-Boot that shall be used for
all systems, unless it is really impossible on a board to implement an
exception from that rule.

> > you just got lucky).  The CFI driver was the outlier - all the other
> > flash code was treating the start field as a VA already.  So I don't
> > think just  reverting the patch is the answer.

We did not even have any notion of VA's in U-Boot until very
recently, and I call on everybody not to make U-Boot more complicated
than necessary.

In almost all cases RAM and NOR flash fit easily in the physical
address space of the CPUs, and for the sake of this majority of
systems it must be possible to access memory on such systems assuming
a simple 1:1 mapping.


Becky: the fact that Haavard's code is breaking is not considered an
indication of a deficiency in his code.

If the CFI driver kind of allowed for VAs before (but incompletely /
incorrectly), then this dis not cause problems on any systems using a
strict 1:1 mapping.

Any changes to the code to correctly support other mappings must be
done in a way that they (1) do not break and (2) do not add additional
burdon on systems with a simple 1:1 mapping.


> > Everything is treated as virtual unless it's being used for hardware  
> > setup.

Thisis NOT correct. U-Boot usually does NOT use virtual addresses.
Only very few systems do, and these must care not to disturb the
majority of systems which do no need to differentiate between
physical and virtual addresses.

> >  If you use something to do memory accesses, it's virtual.

Unless you have a very special system you can rely on a strict 1:1
mapping.

> >  A  
> > lot of code had been just using the PA as a VA, because things were  
> > always mapped 1-1.

Not only were, but _are_ and _will_be_.

> There are basically two ways to fix it: Either go back to using
> physical addresses in the flash API, or make CONFIG_ENV_ADDR virtual

I understand we cannot do that, because some systems need to map (NOR)
flash to virtual addresses outside the physical address space. Ok, so
the CFI driver shall consistently be able to use VAs - but on simple
systems with a 1:1 mapping there shall be no need in the system
configuration to spend any thoughts on this.

> (and from what I hear, the jffs2 code needs a similar fix.) This patch
> does the latter, but it seems like it doesn't fix things
> completely, and Wolfgang didn't appear very happy about it.

Indeed I'm deeply trouble when log standing rules get silently bent
and even broken.

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
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."