Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Bill Fink]

On Sun, 2 Dec 2001, Tom Rini wrote:

> Wasn't there a tool to fiddle and store the vmode/cmode stuff into NVRAM
> tho which would probably work with all of the other cards?

nvvideo, which could set either a video-mode or a color-mode, but I
don't think the color-mode was the same thing as the cmode.  I had to
use a color-mode of 3 IIRC (with a video-mode of 18) to get a decent
display on a 7200 at work (which had a platinum FB IIRC).

						-Bill


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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Benjamin Herrenschmidt]

>> Wasn't there a tool to fiddle and store the vmode/cmode stuff into NVRAM
>> tho which would probably work with all of the other cards?
>
>nvvideo, which could set either a video-mode or a color-mode, but I
>don't think the color-mode was the same thing as the cmode.  I had to
>use a color-mode of 3 IIRC (with a video-mode of 18) to get a decent
>display on a 7200 at work (which had a platinum FB IIRC).

Same problem, the information there is driver specific and the
tool currently use a fix offset instead of properly handling the
nvram device tree extension format (afaik). The cmode is also a
driver specific thing and is equivalent to the MacOS driver
"DepthMode" setting, which will map differently to bit depths
depending on the MacOS driver you are dealing with.

Ben.


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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Tom Rini]

On Mon, Dec 03, 2001 at 12:59:53AM +0100, Benjamin Herrenschmidt wrote:

> Same problem, the information there is driver specific and the

I prefer feature. :)

> tool currently use a fix offset instead of properly handling the
> nvram device tree extension format (afaik). The cmode is also a
> driver specific thing and is equivalent to the MacOS driver
> "DepthMode" setting, which will map differently to bit depths
> depending on the MacOS driver you are dealing with.

If we're writing at a fixed location, and reading from a fixed location,
wouldn't it work (albiet not happily with MacOS?).  That's what I was
getting at.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Tom Rini]

Hello all.  The following patches make slight changes to the vmode/cmode
logic on a few fb drivers.  Now everone consistantly only tries to get
these modes from nvram if CONFIG_NVRAM is defined (otherwise a
compile-time error on everyone but atyfb).  On imsttfb I made the logic
only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which
shouldn't be needed now).  However, I have none of this hardware, and I
remember some of these drivers being very touchy.  So could people with
this hardware apply the patch and let me know if it works still?

Maintainers, does this look right?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

===== drivers/video/controlfb.c 1.9 vs edited =====
--- 1.9/drivers/video/controlfb.c	Fri Nov 16 02:58:17 2001
+++ edited/drivers/video/controlfb.c	Mon Nov 26 22:52:28 2001
@@ -621,14 +621,10 @@

 	full = p->total_vram == 0x400000;

+#ifdef CONFIG_NVRAM
 	/* Try to pick a video mode out of NVRAM if we have one. */
-	if (default_cmode == CMODE_NVRAM){
+	if (default_cmode == CMODE_NVRAM)
 		cmode = nvram_read_byte(NV_CMODE);
-		if(cmode < CMODE_8 || cmode > CMODE_32)
-			cmode = CMODE_8;
-	} else
-		cmode=default_cmode;
-
 	if (default_vmode == VMODE_NVRAM) {
 		vmode = nvram_read_byte(NV_VMODE);
 		if (vmode < 1 || vmode > VMODE_MAX ||
@@ -639,15 +635,16 @@
 			if (control_mac_modes[vmode - 1].m[full] < cmode)
 				vmode = VMODE_640_480_60;
 		}
-	} else {
-		vmode=default_vmode;
-		if (control_mac_modes[vmode - 1].m[full] < cmode) {
-			if (cmode > CMODE_8)
-				cmode--;
-			else
-				vmode = VMODE_640_480_60;
-		}
 	}
+#endif
+
+	/* If we didn't get something from NVRAM, pick a
+	 * sane default.
+	 */
+	if (vmode <= 0 || vmode > VMODE_MAX)
+		vmode = VMODE_640_480_67;
+	if (cmode < CMODE_8 || cmode > CMODE_32)
+		cmode = CMODE_8;

 	if (mac_vmode_to_var(vmode, cmode, &var) < 0) {
 		/* This shouldn't happen! */
===== drivers/video/imsttfb.c 1.11 vs edited =====
--- 1.11/drivers/video/imsttfb.c	Fri Nov 16 02:58:18 2001
+++ edited/drivers/video/imsttfb.c	Mon Nov 26 22:52:11 2001
@@ -371,7 +371,6 @@
 	TVP = 1
 };

-#define USE_NV_MODES		1
 #define INIT_BPP		8
 #define INIT_XRES		640
 #define INIT_YRES		480
@@ -384,7 +383,8 @@
 static char curblink __initdata = 1;
 static char noaccel __initdata = 0;
 #if defined(CONFIG_PPC)
-static signed char init_vmode __initdata = -1, init_cmode __initdata = -1;
+static signed char init_vmode __initdata = VMODE_NVRAM;
+static signed char init_cmode __initdata = CMODE_NVRAM;
 #endif

 static struct imstt_regvals tvp_reg_init_2 = {
@@ -1804,20 +1804,25 @@
 		}
 	}

-#if USE_NV_MODES && defined(CONFIG_PPC)
+#ifdef CONFIG_ALL_PPC
 	{
 		int vmode = init_vmode, cmode = init_cmode;

-		if (vmode == -1) {
+#ifdef CONFIG_NVRAM
+		/* Attempt to read vmode/cmode from NVRAM */
+		if (vmode == VMODE_NVRAM)
 			vmode = nvram_read_byte(NV_VMODE);
-			if (vmode <= 0 || vmode > VMODE_MAX)
-				vmode = VMODE_640_480_67;
-		}
-		if (cmode == -1) {
+		if (cmode == CMODE_NVRAM)
 			cmode = nvram_read_byte(NV_CMODE);
-			if (cmode < CMODE_8 || cmode > CMODE_32)
-				cmode = CMODE_8;
-		}
+#endif
+		/* If we didn't get something from NVRAM, pick a
+		 * sane default.
+		 */
+		if (vmode <= 0 || vmode > VMODE_MAX)
+			vmode = VMODE_640_480_67;
+		if (cmode < CMODE_8 || cmode > CMODE_32)
+			cmode = CMODE_8;
+
 		if (mac_vmode_to_var(vmode, cmode, &p->disp.var)) {
 			p->disp.var.xres = p->disp.var.xres_virtual = INIT_XRES;
 			p->disp.var.yres = p->disp.var.yres_virtual = INIT_YRES;
===== drivers/video/platinumfb.c 1.5 vs edited =====
--- 1.5/drivers/video/platinumfb.c	Fri Nov 16 13:45:57 2001
+++ edited/drivers/video/platinumfb.c	Tue Nov 27 07:53:20 2001
@@ -558,19 +558,20 @@
 	sense = read_platinum_sense(info);
 	printk(KERN_INFO "Monitor sense value = 0x%x, ", sense);

+#ifdef CONFIG_NVRAM
 	if (default_vmode == VMODE_NVRAM) {
 		default_vmode = nvram_read_byte(NV_VMODE);
 		if (default_vmode <= 0 || default_vmode > VMODE_MAX ||
 		    !platinum_reg_init[default_vmode-1])
 			default_vmode = VMODE_CHOOSE;
 	}
-	if (default_vmode == VMODE_CHOOSE) {
+	if (default_cmode == CMODE_NVRAM)
+		default_cmode = nvram_read_byte(NV_CMODE);
+#endif
+	if (default_vmode == VMODE_CHOOSE)
 		default_vmode = mac_map_monitor_sense(sense);
-	}
 	if (default_vmode <= 0 || default_vmode > VMODE_MAX)
 		default_vmode = VMODE_640_480_60;
-	if (default_cmode == CMODE_NVRAM)
-		default_cmode = nvram_read_byte(NV_CMODE);
 	if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
 		default_cmode = CMODE_8;
 	/*
===== drivers/video/valkyriefb.c 1.5 vs edited =====
--- 1.5/drivers/video/valkyriefb.c	Fri Nov 16 13:45:58 2001
+++ edited/drivers/video/valkyriefb.c	Tue Nov 27 07:53:44 2001
@@ -444,6 +444,7 @@
 	p->sense = read_valkyrie_sense(p);
 	printk(KERN_INFO "Monitor sense value = 0x%x, ", p->sense);

+#ifdef CONFIG_NVRAM
 	/* Try to pick a video mode out of NVRAM if we have one. */
 	if (default_vmode == VMODE_NVRAM) {
 		default_vmode = nvram_read_byte(NV_VMODE);
@@ -452,13 +453,14 @@
 		 || !valkyrie_reg_init[default_vmode - 1])
 			default_vmode = VMODE_CHOOSE;
 	}
+	if (default_cmode == CMODE_NVRAM)
+		default_cmode = nvram_read_byte(NV_CMODE);
+#endif
+
 	if (default_vmode == VMODE_CHOOSE)
 		default_vmode = mac_map_monitor_sense(p->sense);
 	if (!valkyrie_reg_init[default_vmode - 1])
 		default_vmode = VMODE_640_480_67;
-	if (default_cmode == CMODE_NVRAM)
-		default_cmode = nvram_read_byte(NV_CMODE);
-
 	/*
 	 * Reduce the pixel size if we don't have enough VRAM or bandwitdh.
 	 */
===== drivers/video/aty/atyfb_base.c 1.6 vs edited =====
--- 1.6/drivers/video/aty/atyfb_base.c	Wed Oct 31 09:09:50 2001
+++ edited/drivers/video/aty/atyfb_base.c	Mon Nov 26 22:39:15 2001
@@ -258,7 +258,7 @@
 #endif

 #ifdef CONFIG_PPC
-#ifdef CONFIG_NVRAM_NOT_DEFINED
+#ifndef CONFIG_NVRAM
 static int default_vmode __initdata = VMODE_NVRAM;
 static int default_cmode __initdata = CMODE_NVRAM;
 #else

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Geert Uytterhoeven]

On Tue, 27 Nov 2001, Tom Rini wrote:
> Hello all.  The following patches make slight changes to the vmode/cmode
> logic on a few fb drivers.  Now everone consistantly only tries to get
> these modes from nvram if CONFIG_NVRAM is defined (otherwise a
> compile-time error on everyone but atyfb).  On imsttfb I made the logic
> only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which
> shouldn't be needed now).  However, I have none of this hardware, and I
> remember some of these drivers being very touchy.  So could people with
> this hardware apply the patch and let me know if it works still?

I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in
macmodes.c, so all drivers will automagically use it for the default video
mode.

The same with MAC monitor sense information, just pass it to mac_find_mode().

So mac_find_mode() should do this:

  - if default mode specified, try that
  - if MAC monitor sense specified, try that
  - if NVRAM, try that
  - fall back to default mode database walking

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Benjamin Herrenschmidt]

>I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in
>macmodes.c, so all drivers will automagically use it for the default video
>mode.
>
>The same with MAC monitor sense information, just pass it to mac_find_mode().
>
>So mac_find_mode() should do this:
>
>  - if default mode specified, try that
>  - if MAC monitor sense specified, try that
>  - if NVRAM, try that
>  - fall back to default mode database walking

No, the NVRAM stuff is driver dependant unfortunately. It's almost common
among drivers for old stuffs like control, chips, etc..., but that is not
the case for recent MacOS drivers. Apple no longer defines a single mode
table, each video driver is now responsible to have it's own mecanism for
that and for storing whatever proprety for saving the mode to nvram. In
fact; the old nvram location is a hack that won't work in all cases as
it's not in xpram any more, it's part of the "device tree extension" part
of the nvram (persistent properties added to selected nodes of the
device-tree).

Ben.

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Tom Rini]

On Fri, Dec 28, 2001 at 12:28:02PM +0100, Benjamin Herrenschmidt wrote:
> >
> >I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in
> >macmodes.c, so all drivers will automagically use it for the default video
> >mode.
> >
> >The same with MAC monitor sense information, just pass it to mac_find_mode().
> >
> >So mac_find_mode() should do this:
> >
> >  - if default mode specified, try that
> >  - if MAC monitor sense specified, try that
> >  - if NVRAM, try that
> >  - fall back to default mode database walking
>
> No, the NVRAM stuff is driver dependant unfortunately. It's almost common
> among drivers for old stuffs like control, chips, etc..., but that is not
> the case for recent MacOS drivers. Apple no longer defines a single mode
> table, each video driver is now responsible to have it's own mecanism for
> that and for storing whatever proprety for saving the mode to nvram. In
> fact; the old nvram location is a hack that won't work in all cases as
> it's not in xpram any more, it's part of the "device tree extension" part
> of the nvram (persistent properties added to selected nodes of the
> device-tree).

Wasn't there a tool to fiddle and store the vmode/cmode stuff into NVRAM
tho which would probably work with all of the other cards?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Martin Costabel]

Tom Rini wrote:
>
> Hello all.  The following patches make slight changes to the vmode/cmode
> logic on a few fb drivers.  Now everone consistantly only tries to get
> these modes from nvram if CONFIG_NVRAM is defined (otherwise a
> compile-time error on everyone but atyfb).  On imsttfb I made the logic
> only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which
> shouldn't be needed now).  However, I have none of this hardware, and I
> remember some of these drivers being very touchy.  So could people with
> this hardware apply the patch and let me know if it works still?

For the valkyriefb driver on my Pmac 6400, I can confirm from a first
short test that it still works. This is with your patch applied to
today's 2.4.17-pre1-ben0 kernel.

I am not testing it very extensively, because this kernel crashes on me
as soon as pppd is started. Yesterday's 2.4.16-ben0 crashed when running
ping. Even on my iBook, the 2.4.16 gave me an "illegal lseek" when
trying to run ping (the 2.4.17-pre1 seems to work OK on the iBook).
Since the 6400 is serving as an adsl router, I prefer to go back to the
stable 2.4.0-pmac kernel from last January.

--
Martin

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Paul Mackerras]

Martin Costabel writes:

> For the valkyriefb driver on my Pmac 6400, I can confirm from a first
> short test that it still works. This is with your patch applied to
> today's 2.4.17-pre1-ben0 kernel.

Do you still have macos on the 6400?  If so can you confirm whether,
if you set the screen resolution and colour depth in macos, that the
value you have set in macos is the default that linux will use?

The nvram locations that the video drivers look in for the default
resolution and depth, 0x140f and 0x1410, were locations that I found
empirically on a 7500 with a control display, and IIRC they also
seemed to work with the platinum and probably the valkyrie as well.
But from about when Apple started to use the ATI chips it seems that
macos changed the way it stored the way it stores the defaults, and
certainly now it is driver-dependent.

Therefore unless someone can reverse-engineer how the macos ATI driver
stores its defaults, I don't think there is any point having the nvram
stuff in the atyfb driver, and it probably isn't doing any good in the
matrox or imstt drivers either.

Paul.

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Martin Costabel]

Paul Mackerras wrote:
>
> Martin Costabel writes:
>
> > For the valkyriefb driver on my Pmac 6400, I can confirm from a first
> > short test that it still works. This is with your patch applied to
> > today's 2.4.17-pre1-ben0 kernel.
>
> Do you still have macos on the 6400?  If so can you confirm whether,

Yes, I still have MacOS 8.6. No 9.x, though.

> if you set the screen resolution and colour depth in macos, that the
> value you have set in macos is the default that linux will use?

I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).

The results, with or without Tom's patch, were the same as they always
were:
The vmode of MacOS is used by the Linux console; the cmode 16 is not
recognized, so instead of vmode 10 16 one always gets vmode 10 8 as
default. The log says

kernel: Monitor sense value = 0x62b, <6>using video mode 10 and color
mode 0

I think I never saw this differently. For 16bit color, I always had to
either put video=valkyriefb:vmode:10,cmode:16 into the kernel args or
say vmode 10 16 at the console (and then startx -- -depth 15 to get the
right colors in X; -depth 16 gives weird colors).

P.S. Rebooting into MacOS (first time for almost a year) seems to have
cured the crashes I had yesterday, too. Weird.

--
Martin

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Paul Mackerras]

Martin Costabel writes:

> I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
> 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).
>
> The results, with or without Tom's patch, were the same as they always
> were:
> The vmode of MacOS is used by the Linux console; the cmode 16 is not
> recognized, so instead of vmode 10 16 one always gets vmode 10 8 as
> default. The log says
>
> kernel: Monitor sense value = 0x62b, <6>using video mode 10 and color
> mode 0

Ben H has just pointed out to me that macos stores some extra
device-tree properties in nvram, and uses that to store the default
resolution and depth.  For the control display, it uses a "gprf"
property, 8 bytes long, and in fact the 2nd and 3rd bytes are what we
are looking at.  Unfortunately OF doesn't add the nvram properties to
the device tree, but Ben seems to think we can add code to do that in
the kernel.

So it would be very interesting to see a dump of nvram on your machine
with the screen set to the different resolution/depth settings in
macos.  Also, if you have the DisplayNameRegistry app under macos,
open it and look at the properties on the valkyrie and see if there is
one with a little "chip" icon (looks like a 6-legged insect to me but
apparently it is supposed to be a chip :).

Paul.

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Geert Uytterhoeven]

On Sun, 2 Dec 2001, Martin Costabel wrote:
> Paul Mackerras wrote:
> > Martin Costabel writes:
> > > For the valkyriefb driver on my Pmac 6400, I can confirm from a first
> > > short test that it still works. This is with your patch applied to
> > > today's 2.4.17-pre1-ben0 kernel.
> >
> > Do you still have macos on the 6400?  If so can you confirm whether,
>
> Yes, I still have MacOS 8.6. No 9.x, though.
>
> > if you set the screen resolution and colour depth in macos, that the
> > value you have set in macos is the default that linux will use?
>
> I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
> 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).
>
> The results, with or without Tom's patch, were the same as they always
> were:
> The vmode of MacOS is used by the Linux console; the cmode 16 is not
> recognized, so instead of vmode 10 16 one always gets vmode 10 8 as
> default. The log says
>
> kernel: Monitor sense value = 0x62b, <6>using video mode 10 and color
> mode 0

<video/macmodes.h>:

| #define CMODE_8                 0       /* 8 bits/pixel */
| #define CMODE_16                1       /* 16 (actually 15) bits/pixel */
| #define CMODE_32                2       /* 32 (actually 24) bits/pixel */

So please try `cmode 1' instead of `cmode 16'.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Tom Rini]

On Mon, Dec 03, 2001 at 02:16:04PM +0100, Geert Uytterhoeven wrote:
> On Sun, 2 Dec 2001, Martin Costabel wrote:
> > Paul Mackerras wrote:
> > > Martin Costabel writes:
> > > > For the valkyriefb driver on my Pmac 6400, I can confirm from a first
> > > > short test that it still works. This is with your patch applied to
> > > > today's 2.4.17-pre1-ben0 kernel.
> > >
> > > Do you still have macos on the 6400?  If so can you confirm whether,
> >
> > Yes, I still have MacOS 8.6. No 9.x, though.
> >
> > > if you set the screen resolution and colour depth in macos, that the
> > > value you have set in macos is the default that linux will use?
> >
> > I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
> > 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).
> >
> > The results, with or without Tom's patch, were the same as they always
> > were:
> > The vmode of MacOS is used by the Linux console; the cmode 16 is not
> > recognized, so instead of vmode 10 16 one always gets vmode 10 8 as
> > default. The log says
> >
> > kernel: Monitor sense value = 0x62b, <6>using video mode 10 and color
> > mode 0
>
> <video/macmodes.h>:
>
> | #define CMODE_8                 0       /* 8 bits/pixel */
> | #define CMODE_16                1       /* 16 (actually 15) bits/pixel */
> | #define CMODE_32                2       /* 32 (actually 24) bits/pixel */
>
> So please try `cmode 1' instead of `cmode 16'.

These bits of code are always different still I think.  Valkyriefb for
example parses 'cmode:{8,15,16}' and does CMODE_8 or CMODE_16.  I
_think_ the userland tools did both 0/1/2 and 8/15/16/32 (24?).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb

[Martin Costabel]

Tom Rini wrote:
>
> On Mon, Dec 03, 2001 at 02:16:04PM +0100, Geert Uytterhoeven wrote:
> > On Sun, 2 Dec 2001, Martin Costabel wrote:
> > > Paul Mackerras wrote:
> > > > Martin Costabel writes:
[]
> > So please try `cmode 1' instead of `cmode 16'.
>
> These bits of code are always different still I think.  Valkyriefb for
> example parses 'cmode:{8,15,16}' and does CMODE_8 or CMODE_16.  I
> _think_ the userland tools did both 0/1/2 and 8/15/16/32 (24?).

I'll be happy to let my 6400 play the guinea pig, but I have to excuse
him until next week; I'm not at home right now.

--
Martin

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