Hi Claude,
Claude wrote:
With regard to my init problems, I think I have found the problem. What really
halts is the function __flush_cache_all() that is called by do_mmap(). In my
case (working with MCF5282) this is an inline function that implements some
assembly code, in particular the following one:
static inline void __flush_cache_all(void)
{
...
#if defined(CONFIG_M527x) || defined(CONFIG_M528x)
__asm__ __volatile__ (
"movel #0x81400100, %%d0\n\t"
"movec %%d0, %%CACR\n\t"
"nop\n\t"
: : : "d0" );
#endif /* CONFIG_M527x || CONFIG_M528x */
...
}
As I can see, this code affects the MCF5282's CACHE module which, according to
Freescale's MCF5282 device errata, it does not work. I have revised the
initial start up code (i.e. head.S) and the macro CACHE_ENABLE is always
called. Thus, I have uClinux playing with a dangerous toy: the MCF5282's
cache.
Yes, older versions of the 5282 silicon had a broken cache.
It used to be that the uClinux kernel (at least for 2.4.x)
by default did not enable the cache on the 5282.
This was change a while back now - on the thinking that there
was very few of the early revision broken parts around :-)
I know that the answer to my problem may be trivial: just disable CACHE. The
question is that I don't know whether there are other modules that may use
CACHE as __flush_cache_all() does. Although I could disable cache in the
start up code, functions as __flush_cache_all would activate it again.
There should only be the 2 places that you would need to disable
this. The head.S call that inits it and the code in cacheflush.h.
I would disable the code completely in both these places, so
there can be accidental re-enabling of the cache.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
