Patch SR71K support - questions

[Louis Hamilton <hamilton@redhat.com>]

Hello,

First a little background for the problem I'm looking at:
I picked up an SR71000 support patch (from Jason Gunthorpe <jgg@debian.org>
sent to this list) and have applied it to our 2.4 MIPS kernel tree. 
 This is a Sandcraft
EV-SR71000-500 cpu module running on a Galileo EV-64240-BP base board in big
endian mode.

What happens is the kernel comes up to the point in init where /sbin/init is
execve'd and hangs (or waits) forever.  Since our QED RM7000 module 
(which we
also ported) is able to bootup all the way we don't suspect file system 
problems.

This board has the PMON Galileo Technology monitor ver. 1.4 in 8-bit 
flash which
does some SR71K cache init by doing a secondary/tertiary flash 
initialize operation
as outlined in the SR71K Cpu Spec in section 7.5.18.

At the load_mmu stage of bring-up I noticed I cannot call the 
"clear_enable_caches"
routine without suffering an exeception.  This is in 
arch/mips/mm/c-sr71000.c, routine
ld_mmu_sr71000 where the call is made to clear_enable_caches as a KSEG1 
address.
I noticed the config register K0 is already set (before load_mmu) to 0x3 
(Cached, Write-back)
and that L2, L3 are enabled, no doubt due to some init done by the PMON 
monitor.
Temporarily commenting out the call to clear_enable_caches step, the 
kernel gets past
the exception problem and progresses to the point where execve seems to 
hang.

So my questions are:
Is this the latest SR71K support patch?  (I can't get access in my 
browser to
http://oss.sgi.com/mips/archive to see prior postings on this...)
Is anyone else using this patch?
If so, is it working ok and what hardware flavor(s) are you using?
What SR71K cpu init is your bootloader or monitor doing before your 
kernel runs?
Any ideas why the tag init loop and secondary/tertiary flash invalidate 
step in
clear_enable_caches crashes the boot-up?

Tia, Louis

Louis Hamilton
Red Hat, Inc.
hamilton@redhat.com