Dear Semih Hazar,
In message 4B6B004C.1010507@indefia.com you wrote:
The problem with AVR32 and the CFI flash driver has a few possible solutions as noted by Haavard Skinnemoen in the email [1]. The only thing I can do is to go with the first alternative and set the flash address as the virtual address which is cache-disabled and works flawless with the CFI driver.
That solution can also be used by other AVR32 boards, and I _think_ it also solves the JFFS2 scanning problem which was mentioned in [2].
The only ugly thing (for me) is when using the CFI commands, the flash addresses has to be shifted by 0xa0000000. (e.g. copy to flash at 0x1000 must be written as cp.b <source> 0xa0001000 <size>).
I really dislike such an approach. From the user interface point of view this is unacceptable to me.
My understanding is that there are only three pretty local areas where uncached access to the flash is needed: initialization (i. e. probing and querying), erasing, and programming.
So it should be possible to switch off caching when entering these functions, and turn it on again upon return. Eventually other architectures might want to implement such a feature, too, so adding generic infrastructure to do that makes sense to me.
Stefan might want to comment here, too ?
In worst case (if you really cannot change the caching attributes for the flash memory region on the fly) it might even be possible to add some "address offset" which is strictly internal to the CFI driver and used for the nn-cached accesses. But in now way any of this should be visible to the end user on the command line.
Best regards,
Wolfgang Denk