On Wed, Oct 23, 2002 at 06:47:27AM -0400, Dinesh Nagpure wrote: > I am almost done with my porting of kernel 2.4.16 to our platform using > RM5231A. But I had to make a couple of very basic hacks and I am trying to > understand if there is any way I can avoid them. > First the memcpy wouldn't work for me properly, both the compiler generated > and also the one under arch/mips/lib/memcpy.c, so I had to change the lib > version to do byte copy. I know this is a very crude change but things > worked. Memcpy.c? I assume that's a typo. We retired the C version of memcopy like 5 years ago. Memcpy.S recently received a few fixes but those were only rather estotheric special cases; chances are these bugs are not what's hitting you. > Second, the Kseg0 coherency algorithm selection in the function > ld_mmu_r4xx0( ) seems to be improper for RM5231A, This function sets the CP0 > config register K0 field to 3 which as per RM5231A user manual is Cacheable, > noncoherent, write back policy Should this not be set to 0, which is > cacheable, non-coherent, write-through, no write allocate? Caching algorithem 3 is should be right for every uniprocessor MIPS system. The only cache coherency attributes that are standard accross all MIPS CPUs are modes 2 and 3. > Also from the knowledge base I understand there is a cache aliasing problem > associated with RM5231A when page size is set to 4KB. The document > recommends to invalidate the cache before retiring a virtual page OR > coloring of the pages. Can someone tell me if this fix is already taken care > of? For me when I enable caching under "Kernel hacking" my kernel crashes > with page fault, when it tries to run bin/init, consistently. There have been fixes in that are as well since 2.4.16 but nothing that explains crashes as early as when booting init. Ralf
