public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] mips cache and relocate_code()
@ 2006-04-13 16:27 Burch, John T.
  2006-04-14 11:47 ` Anton Wöllert
  0 siblings, 1 reply; 4+ messages in thread
From: Burch, John T. @ 2006-04-13 16:27 UTC (permalink / raw)
  To: u-boot

Code is relocated from flash to RAM in cpu/mips/start.S/relocate_code().
After the code is moved a comment in the code says, "If caches were
enabled,
we would have to flush them here."  Based on code in the same file,
the caches are enabled - and I agree that the data cache needs to be
flushed,
(and instruction cached invalidated to be safe) but it isn't.
Is there a reason it's not?
 
Also, flush_cache() is not implemented in cpu/mips/cpu.c.  This function
appears
to be required by cmd_net.c/netboot_common().  Is there a reason
flush_cache()
is not implemented?

I ask because I'm seeing unexplained code behavior that goes away if I
don't 
enable the caches.

John
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] mips cache and relocate_code()
  2006-04-13 16:27 [U-Boot-Users] mips cache and relocate_code() Burch, John T.
@ 2006-04-14 11:47 ` Anton Wöllert
  2006-05-23  9:59   ` Daniel Laird
  0 siblings, 1 reply; 4+ messages in thread
From: Anton Wöllert @ 2006-04-14 11:47 UTC (permalink / raw)
  To: u-boot

Burch, John T. schrieb:
> Code is relocated from flash to RAM in cpu/mips/start.S/relocate_code().
> After the code is moved a comment in the code says, "If caches were
> enabled,
> we would have to flush them here."  Based on code in the same file,
> the caches are enabled - and I agree that the data cache needs to be
> flushed,
> (and instruction cached invalidated to be safe) but it isn't.
> Is there a reason it's not?
>  
> Also, flush_cache() is not implemented in cpu/mips/cpu.c.  This function
> appears
> to be required by cmd_net.c/netboot_common().  Is there a reason
> flush_cache()
> is not implemented?
> 
> I ask because I'm seeing unexplained code behavior that goes away if I
> don't 
> enable the caches.

Hi, the reason why the cache is not flushed, is that
mips_cache_lock(stack pointer) (or so) is called before. This locks
the whole data cache beginning from the stack pointer. Any other
access to other addresses will not get into dcache, because the dcache
lines are locked against replacing. See MIPS spec. Unfortunately the
cache locking don't have to be implemented for MIPS 32 4Kc cpus. So
the code i think has to be improved. I've implemented a fluch_cache
routine to avoid the false behaviour, because the bcm47xx in my case 
doesn't support it (as it seems for me). On the other side icache don't
has to be flushed before relocating, because the start code runs
uncached from KSEG1.
So my thoughts  :)


Anton

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] mips cache and relocate_code()
  2006-04-14 11:47 ` Anton Wöllert
@ 2006-05-23  9:59   ` Daniel Laird
  2006-05-23 16:25     ` Anton Wöllert
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Laird @ 2006-05-23  9:59 UTC (permalink / raw)
  To: u-boot

>Hi, the reason why the cache is not flushed, is that
>mips_cache_lock(stack pointer) (or so) is called before. This locks
>the whole data cache beginning from the stack pointer. Any other
>access to other addresses will not get into dcache, because the dcache
>lines are locked against replacing. See MIPS spec. Unfortunately the
>cache locking don't have to be implemented for MIPS 32 4Kc cpus. So
>the code i think has to be improved. I've implemented a fluch_cache
>routine to avoid the false behaviour, because the bcm47xx in my case 
>doesn't support it (as it seems for me). On the other side icache don't
>has to be flushed before relocating, because the start code runs
>uncached from KSEG1.
>So my thoughts  :)
>Anton
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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users



--
View this message in context: http://www.nabble.com/mips+cache+and+relocate_code%28%29-t1445438.html#a4520308
Sent from the Uboot - Users forum at Nabble.com.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot-Users] mips cache and relocate_code()
  2006-05-23  9:59   ` Daniel Laird
@ 2006-05-23 16:25     ` Anton Wöllert
  0 siblings, 0 replies; 4+ messages in thread
From: Anton Wöllert @ 2006-05-23 16:25 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-23 16:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-13 16:27 [U-Boot-Users] mips cache and relocate_code() Burch, John T.
2006-04-14 11:47 ` Anton Wöllert
2006-05-23  9:59   ` Daniel Laird
2006-05-23 16:25     ` Anton Wöllert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox