[U-Boot-Users] mips cache and relocate_code()

["Anton Wöllert" <a.woellert@gmail.com>]

Daniel Laird:
> I too am going to implement a flush_cache routine to solve some issues.  Are
> you going to feed back your fix for cpu/mips so flush_cache is available to
> all or when i get mine working should i feed mine back?
> cheers
> Dan

Hi Daniel, i've implemented this routine:


void flush_cache (ulong start_addr, ulong size)
{
         ulong start = KSEG0;
         ulong end = KSEG0 + CFG_DCACHE_SIZE;

         if (CFG_CACHELINE_SIZE) {
                 while (start < end) {
                         __asm__ __volatile__("  \
                         .set noreorder;         \
                         .set mips3;             \
                         cache %1, (%0);         \
                         .set mips0;             \
                         .set reorder"           \
                         :
                         : "r" (start),
                           "i" (Index_Writeback_Inv_D));
                         start += CFG_CACHELINE_SIZE;
                 }

         }
}

(in lib_mips/cache.c btw.). But the whole caching is far from complete. 
There are some problems with u-boot. As i mentioned, the mips_cache_lock 
doesn't have to work or the initialising of the cache relies on good 
memory (for zeroing out the tags). And there will be few problems in 
other parts of u-boot that rely on consistent cache (for example the 
eth-packets). So it's not just this routine, more likely the other 
parts, that have to be modified. Of course it's possible to call this 
routine just from the device drivers, but that will be sometimes ugly i 
think. My routine also doesn't flush
the icache because i didn't found any reason for doing that. One thing, 
i also would like to mention is that u-boot doesn't try to get the cache 
line sizes etc. from the cpu. You have to define it! Ok, this saves 
memory and may be easier to configure, but sometimes it would be nice, 
if u-boot could determine the cache stuff dynamically.
So what i want to say, if a good solution is needed for caching on mips, 
then a general clean-up has to be done (supporting the different mips 
cpu types with their specifig cache handling, removing the ugly 
purple-board ifdef's and so on), but if you just want to get your board 
working with caching, you could use this routine as a dirty hack. So my 
thoughts ..

Anton