gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: m68k cacheflushing


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: m68k cacheflushing
Date: 16 Dec 2002 15:05:37 -0500

Greetings!

Richard Zidlicky <address@hidden> writes:

> On Fri, Nov 22, 2002 at 10:50:56PM -0500, Camm Maguire wrote:
> 
> cc'd to linux-m68k where kernel question should go
> 
> > Greetings! gcl/acl2 loads many modules into its data section,
> > relocates, flushes the cache, and then executes the module.
> > The CACHE_LINE granularity option to cacheflush appears to be broken,
> > at least on 060. 
> 
> gcc and glibc use the same already for ages and never had any 
> problems it appears.
> 
> > The following two have been tested and fail, whereas
> > the third has been tested and passes:
> > 
> > 
> > #define CLEAR_CACHE_LINE_SIZE 32
> > #define CLEAR_CACHE do {void 
> > *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> >                         
> > cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_BOTH,ve-v);\
> >                     } while(0)
> > 
> > #define CLEAR_CACHE_LINE_SIZE 32
> > #define CLEAR_CACHE do {void 
> > *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> >                         v=(void *)((unsigned long)v & 
> > ~(CLEAR_CACHE_LINE_SIZE - 1));\
> >                         
> > cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_BOTH,ve-v);\
> >                     } while(0)
> > 
> > #define CLEAR_CACHE_LINE_SIZE 32
> > #define CLEAR_CACHE do {void 
> > *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> >                         v=(void *)((unsigned long)v & 
> > ~(CLEAR_CACHE_LINE_SIZE - 1));\
> >                         
> > cacheflush(v,FLUSH_SCOPE_PAGE,FLUSH_CACHE_BOTH,ve-v);\
> >                     } while(0)
> > 
> > 
> > I haven't tried the remaining cache-line case of rounding ve up to the
> > nearest 32 byte boundary, but barring this, there appears to be an error
> > in the cacheflush kernel function.
> 
> aligning/rounding the address should not be necessary anyway. 

OK, thanks.  I thought so too.

> cacheflush returns 0 on success or -1 and errno so for debugging it 
> would be very good idea to test for errors. The complete range passed 
> to cacheflush must be legal address, otherwise cacheflush will return 
> an error without doing any flush. 
> 

Thanks for this.  Am running now on crest to catch any non-zero
return. 

> Which kernel version was that? Can you see if the failed flushes
> were cornercases like address near page-boundaries? What kind
> of ranges need to be flushed?
> 

2.2.20.  Don't know anything special about the flushed ranges except
         that they are roughly the size of typical .o files (e.g. a few
         k to a few hundred k), and that they are allocated from the
         end of a 32k page memory block attached via sbrk.  I'll
         report any non-zero returns, and any failure without a
         non-zero return when this job finishes.

Take care,


> Richard
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]