* Andrew Isaacson <adi@xxxxxxxxxxxx> [2005-06-22 16:00]: > SB1 does not use the R4K TLB code. > > c->cputype = CPU_SB1; > + c->options &= ~MIPS_CPU_4KTLB; > + c->options |= MIPS_CPU_TLB; > #ifdef CONFIG_SB1_PASS_1_WORKAROUNDS * Daniel Jacobowitz <dan@xxxxxxxxxx> [2005-10-03 09:15]: > > > Well, the flag is not really to specify whether the common code is to be > > > used or not. It's about whether the TLB is like that of the R4k. > > > Actually it's always been a mystery for me why the common code cannot be > > > used for the SB1, but perhaps there is something specific that I could > > > only discover in that "SB-1 Core User Manual" that I yet have to see, > > > sigh... > > > Of course if your TLB is indeed different from that of the R4k, then you > > > shouldn't be setting cp0.config.mt to 1 in the first place... > > The reason was primarily the tiny bit of extra performance because the > > SB1 doesn't need the hazard handling overhead. Also tlb-sb1 has a few > > changes that are needed to initialize a TLB in undefined state after > > powerup. That was needed to run Linux on firmware-less SB1 cores. > FYI, all I have is a piece of hard evidence: this patch was the > difference between not booting and booting for a Sentosa with CFE. > Which isn't firmwareless and isn't a tiny bit of extra performance > issue. > > I'll try to give CVS HEAD a shot this week sometime. * Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> [2005-10-03 14:35]: > > FYI, all I have is a piece of hard evidence: this patch was the > > difference between not booting and booting for a Sentosa with CFE. > > Which isn't firmwareless and isn't a tiny bit of extra performance > > issue. > Actually workarounds have been floating around for some time. ;-) But > I'm glad this has now been fixed properly. There was some discussion regarding this patch but no real conclusion. Is it working without this patch now, or should it be applied (or modified? - how?). -- Martin Michlmayr http://www.cyrius.com/
