progress on l2cr

9 messages, 4 authors, 2000-08-06 · open the first message on its own page

progress on l2cr

From: Guillaume Laur�s <hidden>
Date: 2000-07-17 22:26:52

Hi all,

I've made big improvements in understantding basic kernel code ;-), but
it's still not that good...

Here are two patches against current stable tree, the first,
l2cr-display-gom.diff, fixes the ouput of "cat /proc/sys/kernel.l2cr"
according to M Lanners' patch for G3, and according to the Motorola 7400
Users' Manual.
Tested on G4, but not G3 yet. It should be clean and harmful anyway.

The second, l2cr-cmdline-gom.diff, is a try to enable "l2cr=xx" kernel
command line option.
All is fine if you don't put the option, and hangs at boot with
something like this: l2cr=0xb5100000.
Since when I tried to kill calls to __set_L2CR in ppc_setup_l2cr()
commenting the following two lines:
 _set_L2CR(0);  /* disable cache */
 _set_L2CR(val);  /* enable it */
it stills hangs at the same point, I guess the way I call
ppc_setup_l2cr() is wrong. I couldn't find documentation on this, but I
figured out reading init/main.c that doing this would be sufficient,
tell me were I'm wrong :
--- linux-pmac-stable-orig/init/main.c Mon Jul 17 21:31:00 2000
+++ linux/init/main.c Mon Jul 17 21:04:15 2000
@@ -355,6 +355,9 @@
 #ifdef CONFIG_ADBMOUSE
 extern void adb_mouse_setup(char *str, int *ints);
 #endif
+#ifdef CONFIG_PPC
+extern void ppc_setup_l2cr(char *str, int *ints);
+#endif
 #ifdef CONFIG_WDT
 extern void wdt_setup(char *str, int *ints);
 #endif
@@ -1044,6 +1047,9 @@
 #endif
 #ifdef CONFIG_ADBMOUSE
  { "adb_buttons=", adb_mouse_setup },
+#endif
+#ifdef CONFIG_PPC
+ { "l2cr=", ppc_setup_l2cr },
 #endif
 #ifdef CONFIG_LTPC
  { "ltpc=", ltpc_setup },
Thanks,

--
Guillaume

Re: progress on l2cr

From: Guillaume Laur�s <hidden>
Date: 2000-07-18 06:54:33


Guillaume Laurès a écrit :
[...]-
Here are two patches against current stable tree,
Sorry, they didn't make trough, here there are in the body and in attachement
again :

l2cr-display-gom.diff---------------
--- linux-pmac-stable-orig/arch/ppc/kernel/ppc_htab.c Mon Jul 17 21:30:43
2000
+++ linux-pmac-stable/arch/ppc/kernel/ppc_htab.c Mon Jul 17 22:14:46 2000
@@ -536,8 +536,8 @@
   "unknown size", "256KB", "512KB", "1MB"
  };
  static const char *clockstrings[8] = {
-  "clock disabled", "+1 clock", "+1.5 clock", "reserved(3)",
-  "+2 clock", "+2.5 clock", "+3 clock", "reserved(7)"
+  "clock disabled", "˜1 clock", "˜1.5 clock", "reserved(3)",
+  "˜2 clock", "˜2.5 clock", "˜3 clock", "reserved(7)"
  };
  static const char *typestrings[4] = {
   "flow-through burst SRAM", "reserved SRAM",
@@ -547,6 +547,17 @@
   "0.5", "1.0", "(reserved2)", "(reserved3)"
  };

+ if ((_get_PVR() >> 16) == 12) {
+   /* update those values when CPU is a G4 */
+  sizestrings[0] = "2MB";
+  clockstrings[3] = "˜3.5 clock";
+  clockstrings[3] = "˜4 clock";
+  holdstrings[0] = "0.6";
+  holdstrings[1] = "1.0";
+  holdstrings[2] = "1.4";
+  holdstrings[3] = "1.8";
+ }
+
  if ( ((_get_PVR() >> 16) != 8) && ((_get_PVR() >> 16) != 12))
   return -EFAULT;
@@ -590,25 +601,43 @@
    _set_L2CR(val);
    while ( _get_L2CR() & 0x1 )
     /* wait for invalidate to finish */;
-
+
   } else {
    p = buf;
    if (!first)
     *p++ = '\t';
    val = _get_L2CR();
-   p += sprintf(p, "%08x: ", val);
-   p += sprintf(p, " %s",
-         (val&0x80000000)?"enabled":"disabled");
-   p += sprintf(p,",%sparity",(val&0x40000000)?"":"no ");
-   p += sprintf(p, ",%s", sizestrings[(val >> 28) & 3]);
-   p += sprintf(p, ",%s", clockstrings[(val >> 25) & 7]);
-   p += sprintf(p, ",%s", typestrings[(val >> 23) & 0x2]);
-   p += sprintf(p,"%s",(val>>22)&1?"":",data only");
-   p += sprintf(p,"%s",(val>>20)&1?",ZZ enabled":"");
-   p += sprintf(p,",%s",(val>>19)&1?"write-through":"copy-back");
-   p += sprintf(p,",%sns hold", holdstrings[(val>>16)&3]);
+   p += sprintf(p, "0x%08x: ", val);
+   p += sprintf(p, " %s", (val >> 31) & 1 ? "enabled" :
+     "disabled");
+   p += sprintf(p, ", %sparity", (val>>30)&1 ? "" : "no ");
+   p += sprintf(p, ", %s", sizestrings[(val >> 28) & 3]);
+   p += sprintf(p, ", %s", clockstrings[(val >> 25) & 7]);
+   p += sprintf(p, ", %s", typestrings[(val >> 23) & 2]);
+   p += sprintf(p, "%s", (val>>22)&1 ? ", data only" : "");
+   p += sprintf(p, "%s", (val>>20)&1 ? ", ZZ enabled": "");
+   p += sprintf(p, ", %s", (val>>19)&1 ? "write-through" :
+     "copy-back");
+   p += sprintf(p, "%s", (val>>18)&1 ? ", testing" : "");
+   p += sprintf(p, ", %sns hold",holdstrings[(val>>16)&3]);
+   p += sprintf(p, "%s", (val>>15)&1 ? ", DLL slow" : "");
+   p += sprintf(p, "%s", (val>>14)&1 ? ", diff clock" :"");
+   p += sprintf(p, "%s", (val>>13)&1 ? ", DLL bypass" :"");
+   if ((_get_PVR() >> 16) == 12) {
+     /* G4 have more significant bits than G3 */
+    p += sprintf(p, "%s", (val>>12)&1 ? ",
+      flush assist" :"");
+    p += sprintf(p, "%s", (val>>11)&1 ? ",
+      hardware flush" :"");
+    p += sprintf(p, "%s", (val>>10)&1 ? ",
+      instruction-only" :"");
+    p += sprintf(p, "%s", (val>>9)&1 ? ",
+      clock stop" :"");
+    p += sprintf(p, "%s", (val>>8)&1 ? ",
+      rollover checkstop" :"");
+   }

-   p += sprintf(p,"\n");
+   p += sprintf(p, "\n");

    len = strlen(buf);
    if (len > left)
l2cr-cmdline-gom.diff-----------------------
--- linux-pmac-stable-orig/arch/ppc/kernel/setup.c Mon Jul 17 21:30:43 2000
+++ linux/arch/ppc/kernel/setup.c Mon Jul 17 23:13:58 2000
@@ -549,15 +549,19 @@
  return 0;
 }

-/* Checks "l2cr=xxxx" command-line option */
+/* Takes care of "l2cr=xxxx" command-line option */
 void ppc_setup_l2cr(char *str, int *ints)
 {
  if ( ((_get_PVR() >> 16) == 8) || ((_get_PVR() >> 16) == 12) )
+  /* Make sure cpu is G3 or G4 */
  {
   unsigned long val = simple_strtoul(str, NULL, 0);
   printk(KERN_INFO "l2cr set to %lx\n", val);
-  _set_L2CR(0);
-  _set_L2CR(val);
+  val |= 0x00200000; /* perform global invalidate */
+  _set_L2CR(0);  /* disable cache */
+  _set_L2CR(val);  /* enable it */
+ } else {
+  printk(KERN_INFO "l2cr: cpu is not suitable\n");
  }
 }

--- linux-pmac-stable-orig/init/main.c Mon Jul 17 21:31:00 2000
+++ linux/init/main.c Mon Jul 17 21:04:15 2000
@@ -355,6 +355,9 @@
 #ifdef CONFIG_ADBMOUSE
 extern void adb_mouse_setup(char *str, int *ints);
 #endif
+#ifdef CONFIG_PPC
+extern void ppc_setup_l2cr(char *str, int *ints);
+#endif
 #ifdef CONFIG_WDT
 extern void wdt_setup(char *str, int *ints);
 #endif
@@ -1044,6 +1047,9 @@
 #endif
 #ifdef CONFIG_ADBMOUSE
  { "adb_buttons=", adb_mouse_setup },
+#endif
+#ifdef CONFIG_PPC
+ { "l2cr=", ppc_setup_l2cr },
 #endif
 #ifdef CONFIG_LTPC
  { "ltpc=", ltpc_setup },


@+

--
Guillaume

Re: progress on l2cr

From: Benjamin Herrenschmidt <hidden>
Date: 2000-07-18 08:03:55


Here are two patches against current stable tree, the first,
l2cr-display-gom.diff, fixes the ouput of "cat /proc/sys/kernel.l2cr"
according to M Lanners' patch for G3, and according to the Motorola 7400
Users' Manual.
Tested on G4, but not G3 yet. It should be clean and harmful anyway.

The second, l2cr-cmdline-gom.diff, is a try to enable "l2cr=xx" kernel
command line option.
All is fine if you don't put the option, and hangs at boot with
something like this: l2cr=0xb5100000.
Since when I tried to kill calls to __set_L2CR in ppc_setup_l2cr()
commenting the following two lines:
_set_L2CR(0);  /* disable cache */
_set_L2CR(val);  /* enable it */
it stills hangs at the same point, I guess the way I call
ppc_setup_l2cr() is wrong. I couldn't find documentation on this, but I
figured out reading init/main.c that doing this would be sufficient,
tell me were I'm wrong :
Try my current rsync tree. I merged in some new code from PowerLogix in
the _set_L2CR() function that work around a few CPU erratas and increase
a few things.

You'll notice that when calling _set_L2CR(x) with x!=0, I always OR x
with the invalidate bit to force an invalidation. It's not necessary to
wait for the invaldation to complete inside the ppc_htab.c code however
since it's done inside the _set_L2CR() function in misc.S

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Giuliano Pochini <hidden>
Date: 2000-07-22 01:38:36

+   p += sprintf(p, "%s", (val>>22)&1 ? ", data only" : "");

Is there any reason to keep the L2 cache data-only ?


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Benjamin Herrenschmidt <hidden>
Date: 2000-07-22 20:13:20

Is there any reason to keep the L2 cache data-only ?
There are some rare cases where it can be useful, yes. Like when flushing
it, to avoid the flush code to pollute it.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Benjamin Herrenschmidt <hidden>
Date: 2000-07-31 18:42:28

quoted
quoted
Is there any reason to keep the L2 cache data-only ?
There are some rare cases where it can be useful, yes. Like when flushing
it, to avoid the flush code to pollute it.
A few bytes inside a 1MB cache are't a problem IMHO. Anyway I enabled it and
performance compiling programs is 15% lower.
You have no reason to enable "data only" in normal use. It's used during
the flush cycle of the cache to avoid polluting it while the flush code
runs, but it's set and unset automatically, so you don't need to care.

My latest rsync tree also contains an improved l2cr set routine which
should no longer require Michel's trick to manually disable&flush it
before setting it. It also work around some CPU bugs when DPM (dynamic
power management) is enabled why flushing the L2 cache.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Giuliano Pochini <hidden>
Date: 2000-08-01 00:18:27

quoted
Is there any reason to keep the L2 cache data-only ?
There are some rare cases where it can be useful, yes. Like when flushing
it, to avoid the flush code to pollute it.
A few bytes inside a 1MB cache are't a problem IMHO. Anyway I enabled it and
performance compiling programs is 15% lower.

Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Giuliano Pochini <hidden>
Date: 2000-08-06 03:25:10

quoted
quoted
quoted
Is there any reason to keep the L2 cache data-only ?
There are some rare cases where it can be useful, yes. Like when flushing
it, to avoid the flush code to pollute it.
A few bytes inside a 1MB cache are't a problem IMHO. Anyway I enabled it and
performance compiling programs is 15% lower.
You have no reason to enable "data only" in normal use. It's used during
the flush cycle of the cache to avoid polluting it while the flush code
runs, but it's set and unset automatically, so you don't need to care.
Ok, but /proc/.../l2cr tells it's data-only at boot.

Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: progress on l2cr

From: Timothy A. Seufert <hidden>
Date: 2000-08-06 09:33:17

At 11:25 PM -0400 8/5/00, Giuliano Pochini wrote:
quoted
 >> >Is there any reason to keep the L2 cache data-only ?
 >>
 >> There are some rare cases where it can be useful, yes. Like when flushing
 >> it, to avoid the flush code to pollute it.
 >
 >A few bytes inside a 1MB cache are't a problem IMHO. Anyway I
enabled it and
 >performance compiling programs is 15% lower.

 You have no reason to enable "data only" in normal use. It's used during
 the flush cycle of the cache to avoid polluting it while the flush code
 runs, but it's set and unset automatically, so you don't need to care.
Ok, but /proc/.../l2cr tells it's data-only at boot.
It's lying.

There is a longstanding bug in the kernel L2CR printout routine.  The
kernel routine prints "data only" if the L2DO bit in L2CR is 0.
However, the actual meaning of this bit is 0 = data only mode off, 1
= data only mode on.

This kernel bug probably happened because early revisions of
Motorola's MPC750 manual have several errors in the L2CR section,
including an error about the interpretation of L2DO.  Early revision
Motorola processor manuals are very dangerous things and should not
be relied upon to get anything right (you should see the errata list
for the MPC8260 manual).

Unfortunately, this documentation-caused kernel bug seems to have
slipped through the cracks.


Ben, could you get this patch to fix L2CR reporting into the official
kernel?  It does the following things:

1. Fixes L2DO reporting as discussed above.

2. Fixes cache type reporting (the 2-bit cache memory type field
should be masked using a mask value of 0x03 not 0x02).

3. Sanitizes code so that only one method is used to extract bit
fields from L2CR (better readability)

4. Uses a more sensible format for reporting the L2 cache clock (the
old "+2 clock", "+1.5 clock" stuff doesn't make sense, since we're
reporting the ratio between the processor core clock and the L2 cache
clock, not a delta.)

5. Saves a few bytes of memory by having shorter clock ratio string constants.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help