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

[Haavard Skinnemoen <haavard.skinnemoen@atmel.com>]

On Fri, 28 Aug 2009 14:58:15 -0500
Becky Bruce <becky.bruce@freescale.com> wrote:
> FYI, before the patch, the CFI driver was sometimes doing the map,
> but IIRC it was also abusing the "physical" address, treating it as
> a virtual address without mapping it.

In that case, those places should have been fixed, no?

>  The only way for that to work
> is when VA=PA (or, depending on what you were doing with the address,
> 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.

Except for everything _outside_ the flash code which still deals with
physical addresses, like the environment stuff and JFFS2. The flash
code takes those addresses and compares them with the virtual addresses
in the start array, and things break.

> > So...which config symbols are supposed to be virtual now, and how
> > are you supposed to know how the virtual-to-physical mappings are
> > set up in
> > advance?
> 
> Everything is treated as virtual unless it's being used for hardware  
> setup.

Exactly what constitutes "hardware setup"?

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

Yes, but then the address should also be in a pointer, not an unsigned
long which the flash 'start' array is.

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

Yes, there's lots of code which is broken in that respect...

> Can you point me at an example in your scenario of code that
> interacts with the flash?

CONFIG_ENV_ADDR is used to store the environment in CFI flash. Reading
the environment works OK-ish since the flash is accessible through a
cacheable 1:1 mapping from virtual/physical address 0. However, when
writing and erasing, the physical address stored in CONFIG_ENV_ADDR
appears to be outside of the virtual sector addresses stored in the
'start' array, so the flash code throws an error.

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
(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.

Haavard