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

Stefan Roese sr at denx.de
Sat Aug 29 13:39:02 CEST 2009

On Friday 28 August 2009 21:58:15 Becky Bruce wrote:
> On Aug 28, 2009, at 8:49 AM, Haavard Skinnemoen wrote:
> > Kumar Gala <galak at kernel.crashing.org> wrote:
> >>> Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring
> >>> things
> >>> back to the way they were, and fix both the saveenv problem and the
> >>> jffs2 problem.
> >>
> >> Such a revert would break other boards that now expect the new
> >> behavior (like all the 36-bit physical cfg for FSL boards)
> >
> > Right, I suspected that.
> 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.  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.

I think too, that revering the patch in question is not the right "solution" 
for this problem in the current stage. But I have to admit that I don't have 
enough insight into your platform to come up with another good idea quickly.

> > 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.  If you use something to do memory accesses, it's virtual.  A
> lot of code had been just using the PA as a VA, because things were
> always mapped 1-1.

Correct. All those addresses to configure the CFI driver should be virtual 
addresses. BTW: This is valid for other drivers as well (e.g. IDE, video).

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

Yes, please give us an example of your memory mapping (physical and virtual) 
on your failing platform.


DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

More information about the U-Boot mailing list