MIPS32 cache functions now using c-r4k?

MIPS32 cache functions now using c-r4k?

[Hartvig Ekner]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On a MIPS32 CPU (Au1500), I now end up in:

Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x802d0ab8
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000
Reserved instruction in kernel code in traps.c::do_ri, line 650:
$0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000 80000000
$8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4 00000010
$16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000 00000000
$24: ffffffff 810ebde7                   810ea000 810ebd68 00000000 80121adc
Hi : 00000000
Lo : 000000c0
epc  : 8010965c    Not tainted
Status: 1000fc02
Cause : 00800028
Process swapper (pid: 1, stackpage=810ea000)

Which is:

80109654 <r4k_clear_page_d32>:
80109654:       24811000        addiu   $at,$a0,4096
80109658:       bc8d0000        cache   0xd,0($a0)
8010965c:       fc800000        sdc3    $0,0($a0)
80109660:       fc800008        sdc3    $0,8($a0)
80109664:       fc800010        sdc3    $0,16($a0)
80109668:       fc800018        sdc3    $0,24($a0)
8010966c:       24840040        addiu   $a0,$a0,64
80109670:       bc8dffe0        cache   0xd,-32($a0)
80109674:       fc80ffe0        sdc3    $0,-32($a0)
80109678:       fc80ffe8        sdc3    $0,-24($a0)
8010967c:       fc80fff0        sdc3    $0,-16($a0)
80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4>
80109684:       fc80fff8        sdc3    $0,-8($a0)
80109688:       03e00008        jr      $ra

It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's?

/Hartvig


[-- Attachment #2: Type: text/html, Size: 3675 bytes --]

Re: MIPS32 cache functions now using c-r4k?

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

The whole point of creating the generic MIPS32 MMU and cache
routines was to have something that would run on both 32-bit and
64-bit processors.  Who decided to throw them away and abandon 
support for 32-bit-only CPUs other than the R3000, and why?

            Kevin K.
  ----- Original Message ----- 
  From: Hartvig Ekner 
  To: Linux MIPS mailing list 
  Sent: Wednesday, April 16, 2003 9:54 AM
  Subject: MIPS32 cache functions now using c-r4k?


  On a MIPS32 CPU (Au1500), I now end up in: 
  Mount cache hash table entries: 512 (order: 0, 4096 bytes) 
  Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) 
  Page-cache hash table entries: 16384 (order: 4, 65536 bytes) 
  Checking for 'wait' instruction...  available. 
  POSIX conformance testing by UNIFIX 
  Autoconfig PCI channel 0x802d0ab8 
  Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x44000000 
  Reserved instruction in kernel code in traps.c::do_ri, line 650: 
  $0 : 00000000 810e4000 802d0000 80109654 810e3000 802c4754 00000000 80000000 
  $8 : 8102e720 00000001 8010b98c c0000000 001fffff c0000000 fffffff4 00000010 
  $16: 810e3000 802d1340 802b9800 802bc000 00000000 00000000 00101000 00000000 
  $24: ffffffff 810ebde7                   810ea000 810ebd68 00000000 80121adc 
  Hi : 00000000 
  Lo : 000000c0 
  epc  : 8010965c    Not tainted 
  Status: 1000fc02 
  Cause : 00800028 
  Process swapper (pid: 1, stackpage=810ea000) 

  Which is: 

  80109654 <r4k_clear_page_d32>: 
  80109654:       24811000        addiu   $at,$a0,4096 
  80109658:       bc8d0000        cache   0xd,0($a0) 
  8010965c:       fc800000        sdc3    $0,0($a0) 
  80109660:       fc800008        sdc3    $0,8($a0) 
  80109664:       fc800010        sdc3    $0,16($a0) 
  80109668:       fc800018        sdc3    $0,24($a0) 
  8010966c:       24840040        addiu   $a0,$a0,64 
  80109670:       bc8dffe0        cache   0xd,-32($a0) 
  80109674:       fc80ffe0        sdc3    $0,-32($a0) 
  80109678:       fc80ffe8        sdc3    $0,-24($a0) 
  8010967c:       fc80fff0        sdc3    $0,-16($a0) 
  80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4> 
  80109684:       fc80fff8        sdc3    $0,-8($a0) 
  80109688:       03e00008        jr      $ra 

  It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's? 

  /Hartvig 
    

[-- Attachment #2: Type: text/html, Size: 5492 bytes --]

Re: MIPS32 cache functions now using c-r4k?

[Maciej W. Rozycki]

On Wed, 16 Apr 2003, Kevin D. Kissell wrote:

> The whole point of creating the generic MIPS32 MMU and cache
> routines was to have something that would run on both 32-bit and
> 64-bit processors.  Who decided to throw them away and abandon 
> support for 32-bit-only CPUs other than the R3000, and why?

 It's a plain bug and then a trivial one.  I don't think anybody meant to
abandon MIPS32.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS32 cache functions now using c-r4k?

[Ralf Baechle]

On Wed, Apr 16, 2003 at 02:59:30PM +0200, Kevin D. Kissell wrote:

> The whole point of creating the generic MIPS32 MMU and cache
> routines was to have something that would run on both 32-bit and
> 64-bit processors.  Who decided to throw them away and abandon 
> support for 32-bit-only CPUs other than the R3000, and why?

Nobody did dump support for 32-bit only processors.

The read behind all this was in part that the pile of c-*.c files had
turned into some sort of barbed wire fence.  Code from c-r4k.c had been
replicated several times - including hundreds (conservative estimate) of
lines of dead code, plenty of bugs and lack of understanding how caches
are working.  At the same time that meant there was no way the old code
could have supported all available processor configurations on some
platforms.

So when I was doing some work related to signal handling I finally gave
up and started cleaning the the mess instead of doing the same change
to 42 copies of a function.

The result of the changes aside of a bunch of bugs - at less than 50% of
the binary size and hundreds of kilobytes of less sources a more generic
kernel with for most people dramatically improved performance.  Yes, a
few bugs crept in but I'd do it again at any time.

  Ralf

Re: MIPS32 cache functions now using c-r4k?

[Jun Sun]

On Wed, Apr 16, 2003 at 04:08:19PM +0200, Ralf Baechle wrote:
> On Wed, Apr 16, 2003 at 02:59:30PM +0200, Kevin D. Kissell wrote:
> 
> > The whole point of creating the generic MIPS32 MMU and cache
> > routines was to have something that would run on both 32-bit and
> > 64-bit processors.  Who decided to throw them away and abandon 
> > support for 32-bit-only CPUs other than the R3000, and why?
> 
> Nobody did dump support for 32-bit only processors.
> 
> The read behind all this was in part that the pile of c-*.c files had
> turned into some sort of barbed wire fence.  Code from c-r4k.c had been
> replicated several times - including hundreds (conservative estimate) of
> lines of dead code, plenty of bugs and lack of understanding how caches
> are working.  At the same time that meant there was no way the old code
> could have supported all available processor configurations on some
> platforms.
>

It is really a Good Thing(tm) to have a more uniformed cache routine
and actually an overall performance gain.  It makes the tree more maintainable
and that new abstraction enables us to accomodate any new wacky CPUs
if there dare to any. :)

This is a long overdue task.  And the first derailed c-* file really should
not be allowed at the first place. :)

Jun

Re: MIPS32 cache functions now using c-r4k?

[Maciej W. Rozycki]

On Wed, 16 Apr 2003, Hartvig Ekner wrote:

> Which is:
> 
> 80109654 <r4k_clear_page_d32>:
> 80109654:       24811000        addiu   $at,$a0,4096
> 80109658:       bc8d0000        cache   0xd,0($a0)
> 8010965c:       fc800000        sdc3    $0,0($a0)
> 80109660:       fc800008        sdc3    $0,8($a0)
> 80109664:       fc800010        sdc3    $0,16($a0)
> 80109668:       fc800018        sdc3    $0,24($a0)
> 8010966c:       24840040        addiu   $a0,$a0,64
> 80109670:       bc8dffe0        cache   0xd,-32($a0)
> 80109674:       fc80ffe0        sdc3    $0,-32($a0)
> 80109678:       fc80ffe8        sdc3    $0,-24($a0)
> 8010967c:       fc80fff0        sdc3    $0,-16($a0)
> 80109680:       1424fff5        bne     $at,$a0,80109658 <r4k_clear_page_d32+0x4>
> 80109684:       fc80fff8        sdc3    $0,-8($a0)
> 80109688:       03e00008        jr      $ra
> 
> It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's?

 Not much -- only arch/mips/mm/pg-r4k.S.  It looks like MIPS32 needs an
own implementation -- trivially different and half as fast.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS32 cache functions now using c-r4k?

[Ralf Baechle]

On Wed, Apr 16, 2003 at 09:54:28AM +0200, Hartvig Ekner wrote:

> It seems much of the r4k cache code assumes the presence of SD - which
> breaks on all MIPS32 CPU's?

Nothing a soldering iron and some patience couldn't fix ;)

Try below patch,

  Ralf

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.43
diff -u -r1.3.2.43 c-r4k.c
--- arch/mips/mm/c-r4k.c	16 Apr 2003 12:41:18 -0000	1.3.2.43
+++ arch/mips/mm/c-r4k.c	16 Apr 2003 14:56:03 -0000
@@ -34,6 +34,8 @@
 #include <asm/cacheops.h>
 #include <asm/r4kcache.h>
 
+extern void r4k_clear_page32_d16(void * page);
+extern void r4k_clear_page32_d32(void * page);
 extern void r4k_clear_page_d16(void * page);
 extern void r4k_clear_page_d32(void * page);
 extern void r4k_clear_page_r4600_v1(void * page);
@@ -877,7 +879,10 @@
 
 	switch (current_cpu_data.dcache.linesz) {
 	case 16:
-		_clear_page = r4k_clear_page_d16;
+		if (cpu_has_64bits)
+			_clear_page = r4k_clear_page_d16;
+		else
+			_clear_page = r4k_clear_page32_d16;
 		_copy_page = r4k_copy_page_d16;
 
 		break;
@@ -890,7 +895,10 @@
 			_clear_page = r4k_clear_page_r4600_v2;
 			_copy_page = r4k_copy_page_r4600_v2;
 		} else {
-			_clear_page = r4k_clear_page_d32;
+			if (cpu_has_64bits)
+				_clear_page = r4k_clear_page_d32;
+			else
+				_clear_page = r4k_clear_page32_d32;
 			_copy_page = r4k_copy_page_d32;
 		}
 		break;
Index: arch/mips/mm/pg-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/pg-r4k.S,v
retrieving revision 1.2.2.3
diff -u -r1.2.2.3 pg-r4k.S
--- arch/mips/mm/pg-r4k.S	5 Aug 2002 23:53:35 -0000	1.2.2.3
+++ arch/mips/mm/pg-r4k.S	16 Apr 2003 14:56:07 -0000
@@ -39,6 +39,39 @@
  *   versions of R4000 and R4400.
  */
 
+LEAF(r4k_clear_page32_d16)
+	addiu	AT, a0, _PAGE_SIZE
+1:	cache	Create_Dirty_Excl_D, (a0)
+	sw	zero, (a0)
+	sw	zero, 4(a0)
+	sw	zero, 8(a0)
+	sw	zero, 12(a0)
+	addiu	a0, 32
+	cache	Create_Dirty_Excl_D, -16(a0)
+	sw	zero, -16(a0)
+	sw	zero, -12(a0)
+	sw	zero, -8(a0)
+	sw	zero, -4(a0)
+	bne	AT, a0, 1b
+	jr	ra
+	END(r4k_clear_page32_d16)
+
+LEAF(r4k_clear_page32_d32)
+	addiu	AT, a0, _PAGE_SIZE
+1:	cache	Create_Dirty_Excl_D, (a0)
+	sw	zero, (a0)
+	sw	zero, 4(a0)
+	sw	zero, 8(a0)
+	sw	zero, 12(a0)
+	addiu	a0, 64
+	sw	zero, -16(a0)
+	sw	zero, -12(a0)
+	sw	zero, -8(a0)
+	sw	zero, -4(a0)
+	bne	AT, a0, 1b
+	jr	ra
+	END(r4k_clear_page32_d32)
+
 LEAF(r4k_clear_page_d16)
 	addiu	AT, a0, _PAGE_SIZE
 1:	cache	Create_Dirty_Excl_D, (a0)
Index: include/asm-mips/cpu.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/cpu.h,v
retrieving revision 1.24.2.18
diff -u -r1.24.2.18 cpu.h
--- include/asm-mips/cpu.h	15 Apr 2003 14:19:14 -0000	1.24.2.18
+++ include/asm-mips/cpu.h	16 Apr 2003 14:56:33 -0000
@@ -162,14 +162,20 @@
 
 /*
  * ISA Level encodings
+ *
  */
 #define MIPS_CPU_ISA_I		0x00000001
 #define MIPS_CPU_ISA_II		0x00000002
-#define MIPS_CPU_ISA_III	0x00000003
-#define MIPS_CPU_ISA_IV		0x00000004
-#define MIPS_CPU_ISA_V		0x00000005
+#define MIPS_CPU_ISA_III	0x00008003
+#define MIPS_CPU_ISA_IV		0x00008004
+#define MIPS_CPU_ISA_V		0x00008005
 #define MIPS_CPU_ISA_M32	0x00000020
-#define MIPS_CPU_ISA_M64	0x00000040
+#define MIPS_CPU_ISA_M64	0x00008040
+
+/*
+ * Bit 15 encodes if an ISA level supports 64-bit operations.
+ */
+#define MIPS_CPU_ISA_64BIT	0x00008000
 
 /*
  * CPU Option encodings
Index: include/asm-mips/processor.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/processor.h,v
retrieving revision 1.43.2.18
diff -u -r1.43.2.18 processor.h
--- include/asm-mips/processor.h	15 Apr 2003 14:19:14 -0000	1.43.2.18
+++ include/asm-mips/processor.h	16 Apr 2003 14:56:46 -0000
@@ -93,6 +93,7 @@
 #define cpu_has_vtag_icache	(cpu_data[0].icache.flags & MIPS_CACHE_VTAG)
 #define cpu_has_dc_aliases	(cpu_data[0].dcache.flags & MIPS_CACHE_ALIASES)
 #define cpu_has_ic_fills_f_dc	(cpu_data[0].dcache.flags & MIPS_CACHE_IC_F_DC)
+#define cpu_has_64bits		(cpu_data[0].isa_level & MIPS_CPU_ISA_64BIT)
 
 extern struct cpuinfo_mips cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]

Re: MIPS32 cache functions now using c-r4k?

[Hartvig Ekner]

Hi Ralf,

I'll test it out a little later this evening. But I think there is a typo and this patch should
be applied:

Index: pg-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/pg-r4k.S,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 pg-r4k.S
--- pg-r4k.S    16 Apr 2003 17:00:23 -0000      1.2.2.4
+++ pg-r4k.S    16 Apr 2003 17:46:36 -0000
@@ -63,7 +63,7 @@
        sw      zero, 4(a0)
        sw      zero, 8(a0)
        sw      zero, 12(a0)
-       addiu   a0, 64
+       addiu   a0, 32
        sw      zero, -16(a0)
        sw      zero, -12(a0)
        sw      zero, -8(a0)

/Hartvig


Ralf Baechle wrote:

> On Wed, Apr 16, 2003 at 09:54:28AM +0200, Hartvig Ekner wrote:
>
> > It seems much of the r4k cache code assumes the presence of SD - which
> > breaks on all MIPS32 CPU's?
>
> Nothing a soldering iron and some patience couldn't fix ;)
>
> Try below patch,
>
>   Ralf

Re: MIPS32 cache functions now using c-r4k?

[Ralf Baechle]

On Wed, Apr 16, 2003 at 07:51:35PM +0200, Hartvig Ekner wrote:

> I'll test it out a little later this evening. But I think there is a
> typo and this patch should be applied:

Technically right, so I applied it.

(Usual comment - Mozilla garbles inline patches so while inline patches
are prefered with Mozilla sending them as an attachment is necessary.)

  Ralf