[U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
Stefan Roese
sr at denx.de
Tue Jan 16 07:52:56 CET 2007
Hi Haavard,
On Saturday 13 January 2007 18:53, Håvard Skinnemoen wrote:
> On 1/13/07, Tolunay Orkun <listmember at orkun.us> wrote:
> > Perhaps, more important issue would be if these areas were cached. In
> > that case, every time we change the flash from read mode to special
> > query modes, we should probably invalidate the cache. In PowerPC 405
> > platform our flash is uncached so this is not necessary. I do not know
> > if any platform caches its flash areas.
>
> AVR32 does cache its flash area by default, but it can be worked
> around by specifying an uncached virtual mapping (i.e. the physical
> address ORed with 0xa0000000, similar to MIPS and SH) as the flash
> address instead of the physical address.
>
> However, doing cached flash accesses would probably improve the
> performance of things like fsload, so how about using something like
> the following interface when uncached access is needed?
>
> void *flash_map(unsigned long paddr, size_t len);
> void flash_unmap(void *vaddr, size_t len);
>
> On platforms where the flash is always uncached, flash_map would
> simply return paddr cast as a void *, and flash_unmap would do
> nothing. Other platforms may invalidate the range and return a virtual
> address which will bypass the cache (or simply disable the dcache and
> return the physical address.)
I tend to like this idea of these mapping functions. This would give us more
flexibility. On some 4xx boards for example, we initialize the flash cached
after powerup and switch to uncached access after relocation. We wouldn't
need this change in the TLB's with these mapping functions anymore.
And you are right of course. If implementing such an extension, we should
first make sure that those mapping functions will do nothing on most
platform, so we stay compatible and don't break any existing designs.
If thinking longer about this, I think it would be helpful to make these
mapping functions even more generic. Meaning not flash focused, but generic
mapping functions with a parameter like ioremap in Linux. This way we could
use these function to also map a region as cached or uncached memory if
needed.
Best regards,
Stefan
More information about the U-Boot
mailing list