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

Becky Bruce becky.bruce at freescale.com
Fri Aug 28 21:58:15 CEST 2009


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.

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

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

Your problem
Cheers,
Becky



More information about the U-Boot mailing list