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@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.
Cheers, Stefan
-- 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@denx.de