First a little background for the problem I'm looking at:
I picked up an SR71000 support patch (from Jason Gunthorpe <firstname.lastname@example.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
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
also ported) is able to bootup all the way we don't suspect file system
This board has the PMON Galileo Technology monitor ver. 1.4 in 8-bit
does some SR71K cache init by doing a secondary/tertiary flash
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
routine without suffering an exeception. This is in
ld_mmu_sr71000 where the call is made to clear_enable_caches as a KSEG1
I noticed the config register K0 is already set (before load_mmu) to 0x3
and that L2, L3 are enabled, no doubt due to some init done by the PMON
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
So my questions are:
Is this the latest SR71K support patch? (I can't get access in my
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
Any ideas why the tag init loop and secondary/tertiary flash invalidate
clear_enable_caches crashes the boot-up?
Red Hat, Inc.