[Top][All Lists]
[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