Mark Salter writes:
> >>  Verify that the latest source tree on Llinus compiles and boots
> >> (maybe automate this with a daily build that gets tested)
> > I checked this yesterday when I commited my code to linus.
> Yes, but I bet you didn't check it on an Indy with no scache :-)
> I have one of those beasts and the latest code in the cvs tree
> crashes early in the boot process.
> The code in arch/mips/mm/r4xx0.c which sets up the cache flush
> procs now selects r4k_flush_page_to_ram_d32i32_r4600 where
> earlier versions of r4xx0.c selected r4k_flush_page_to_ram_d32i32.
> I think the current choice is correct in that my Indy has the
> R4600 cache bug mentioned in IDT's errata. But the *_r4600 version
> also has some inline assembler under an ifdef CONFIG_SGI which
> appears to do something to the SGI scache. But since I have
> no scache, I get a bus error irq instead.
> It seems a bit strange that r4k_flush_page_to_ram_d32i32_r4600
> has this bit of SGI specific code, but r4k_flush_page_to_ram_d32i32
> does not. ???
I have not looked at the source, but the problem is probably that
there needs to be two cases, one with and one without Indy R4600 scache.
This is determined by reading out the EEPROM on the CPU board, and looking
at the appropriate bits for "scache present" and "scache size". The
processor will get a bus error trying to reference the control registers
of the scache controller (via uncached memory references) if the secondary
cache is not present.