pismo upgraded to 750fx not detected correctly

pismo upgraded to 750fx not detected correctly

[Chris Studholme]

Hi all,

I have a Powerbook G3 (Pismo) 400MHz that I've been running Linux on for
almost 3 years now.  It has been working great, but to ensure that it
continues to serve me well, I purchased the Powerlogix BlueChip G3 900MHz
upgrade <http://www.powerlogix.com/products2/bcg3pismo/index.html>.  The
machine still runs Linux ok, but I have a few problems.

First off, the new processor is an IBM 750FX, but it is recognized as a
740/750.

  $ cat /proc/cpuinfo
  cpu             : 740/750
  temperature     : 20 C (uncalibrated)
  clock           : 550MHz
  revision        : 2.2 (pvr 0008 0202)
  bogomips        : 1795.68
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 00000007
  L2 cache        : 1024K unified
  memory          : 256MB
  pmac-generation : NewWorld

I believe pvr should be 7000 0202.  Also, the clock speed is 900MHz, not
550MHz.  I have verified, using some numerical cpu bound programs I have,
that this machine is running at least twice as fast as it did before the
upgrade.  Also, note that the bogomips value seems to imply the machine is
actually running at 900MHz.  Finally, the L2 cache is now only 512K, but
included on the processor die running at 900MHz.

I don't know the linux source that well, but it looks to me like these
values are being read from the open firmware and not from the cpu
directly.  Is there a way I can alter linux to double check the values and
correct them if the firmware is wrong?  As a first stab at the problem, I
made the following change to arch/ppc/kernel/cputable.c (in 2.4.20-ben10):

*** cputable.c.orig     Tue May 27 16:38:20 2003
--- cputable.c  Tue May 27 16:42:14 2003
***************
*** 161,166 ****
--- 161,175 ----
        32, 32,
        __setup_cpu_750fx
      },
+     { /* 750FX (Powerlogix Pismo upgrade) */
+       0xffffffff, 0x00080202, "750FX",
+       CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
+       CPU_FTR_L2CR | CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_CAN_NAP |
+       CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS,
+       COMMON_PPC,
+       32, 32,
+       __setup_cpu_750fx
+     },
      { /* 740/750 (L2CR bit need fixup for 740) */
        0xffff0000, 0x00080000, "740/750",
        CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |

This corrects cpuinfo slightly, but is obviously not a very good solution.

  $ cat /proc/cpuinfo
  cpu             : 750FX
  temperature     : 20 C (uncalibrated)
  clock           : 550MHz
  revision        : 2.2 (pvr 0008 0202)
  bogomips        : 1795.68
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 0000000f
  L2 cache        : 1024K unified
  memory          : 256MB
  pmac-generation : NewWorld

Also, note that MacOS also fails to correctly detect the cpu and clock
speed.  To get the correct values and fiddle with the 750fx's fancy
features (like clock speed scaling), I had to install a tool developed by
Powerlogix called CPU Director
<http://www.powerlogix.com/support2/cpudirector/index.html>.

My motivation for this work is not just to get cpuinfo to display the
correct data, but to get cpufreq working on this machine.  With the
following patch to arch/ppc/platforms/pmac_cpufreq.c I think I've come
close.

*** pmac_cpufreq.c.orig Wed May 21 23:33:27 2003
--- pmac_cpufreq.c      Thu Jun 12 14:22:22 2003
***************
*** 19,25 ****
  #include <asm/cputable.h>
  #include <asm/time.h>

! #undef DEBUG_FREQ

  extern void low_choose_750fx_pll(int pll);
  extern void low_sleep_handler(void);
--- 19,25 ----
  #include <asm/cputable.h>
  #include <asm/time.h>

! #define DEBUG_FREQ

  extern void low_choose_750fx_pll(int pll);
  extern void low_sleep_handler(void);
***************
*** 304,309 ****
--- 304,318 ----
                has_freq_ctl = 1;
                cpufreq_uses_pmu = 1;
        }
+       /* Else check for Pismo/Powerlogix 900 */
+       else if (machine_is_compatible("PowerBook3,1")) {
+               printk("CPUFREQ: pismo detected\n");
+               cur_freq = 900000;
+               low_freq = 400000;
+               hi_freq = 900000;
+               cpufreq_uses_pmu = 0;
+               has_freq_ctl = 1;
+       }
        /* Else check for 750FX */
        else if (PVR_VER(mfspr(PVR)) == 0x7000) {
                if (get_property(cpunode, "dynamic-power-step", NULL) == NULL)

After boot with this change, I get:

  $ cat /proc/cpuinfo
  cpu             : 750FX
  temperature     : 20 C (uncalibrated)
  clock           : 900MHz
  revision        : 2.2 (pvr 0008 0202)
  bogomips        : 1795.68
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 0000000f
  L2 cache        : 1024K unified
  memory          : 256MB
  pmac-generation : NewWorld
  $ cat /proc/cpufreq
            minimum CPU frequency  -  maximum CPU frequency  -  policy
  CPU  0       400000 kHz ( 44 %)  -     900000 kHz (100 %)  -  performance

Now, I can try to change processor speed as follows:

  # echo -n "0:0:0:powersave" > /proc/cpufreq
  # cat /proc/cpuinfo
  cpu             : 750FX
  temperature     : 24 C (uncalibrated)
  clock           : 400MHz
  revision        : 2.2 (pvr 0008 0202)
  bogomips        : 798.08
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 0000000f
  L2 cache        : 1024K unified
  memory          : 256MB
  pmac-generation : NewWorld
  # cat /proc/cpufreq
            minimum CPU frequency  -  maximum CPU frequency  -  policy
  CPU  0       400000 kHz ( 44 %)  -     400000 kHz ( 44 %)  -  powersave

And to return to top speed:

  # echo -n "0:900000:900000:performance" > /proc/cpufreq
  # cat /proc/cpuinfo
  cpu             : 750FX
  temperature     : 39 C (uncalibrated)
  clock           : 900MHz
  revision        : 2.2 (pvr 0008 0202)
  bogomips        : 1795.68
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 0000000f
  L2 cache        : 1024K unified
  memory          : 256MB
  pmac-generation : NewWorld
  # cat /proc/cpufreq
            minimum CPU frequency  -  maximum CPU frequency  -  policy
  CPU  0       900000 kHz (100 %)  -     900000 kHz (100 %)  -  performance

Relevent lines from `dmesg` are:

  Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
  Total memory = 256MB; using 512kB for hash table (at c0280000)
  Linux version 2.4.20-ben10 (cvs@achilles) (gcc version 2.95.4 20011002 (Debian prerelease)) #10 Thu May 29 16:51:37 EDT
  Found Uninorth memory controller & host bridge, revision: 7
  Mapped at 0xfdffc000
  Found a Keylargo mac-io controller, rev: 3, mapped at 0xfdf7c000
  Processor NAP mode on idle enabled.
  PowerMac motherboard: PowerBook Pismo
  CPU HID1 : 0x92000000

  .. other stuff ..

  Initializing RT netlink socket
  Thermal assist unit using timers, shrink_timer: 200 jiffies
  CPUFREQ: pismo detected
  Starting kswapd

  .. other stuff ..

  Linux Kernel Card Services 3.1.22
    options:  [pci] [cardbus] [pm]
  Yenta IRQ list 0000, PCI irq58
  Socket status: 30000086
  HID1, before: 92000000
  HID1, after: 92010000
  Calibrating delay loop... 897.84 BogoMIPS
  HID1, before: 92010000
  HID1, after: 92000000
  Calibrating delay loop... 1795.68 BogoMIPS

Note that at low speed (400MHz), the bogomips value reported in cpuinfo is
as expected, but the debug message above seems to indicate a clock speed
of 450MHz.

Anyway, all this appeared quite nice, but it doesn't work.  I wrote the
following little program to try to verify the cpu freq change:

  #include <stdio.h>
  #include <time.h>

  int main() {
    clock_t start,end;
    int i,j;
    do {
      start = clock();
      j = 0;
      for (i=0; i<100*1000*1000; ++i) j+=i;
      end = clock();
      printf("%d\n",(int)(end-start));
    } while (1);
    return 0;
  }

and compiled it without any optimization.  Here's some sample output:

  $ ./speed
  1150000
  1140000
  1140000
  1140000
  1150000
  1150000
  1140000
  1140000
  1120000
  1090000
  1130000
  1140000
  1150000

These lines are output about one per second.  I expect both the number and
the rate at which the lines are output to change by about a factor of 2
when the cpu freq changes; however, this does not happen.

At this point, I'm stuck.  I hope you can provide comments and
suggestions.  Please let me know if there is any more info I can provide
or if there is something else I should try.  Thanks.

Chris.


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

X engine over Video Controller

[Rupesh S]

Hi,

I work with FADS823 board running PPC-Linux.
Now that I plan to put a X-Engine over my Video Controller inbuilt in MPC823
and supported by FADS board.
Need help in selecting the X-Engine and the feasibility of the same with the
above mentioned board.
Also I would like to know if I can get any ind of reference for the same....

Rupesh


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

Re: X engine over Video Controller

[Michel Dänzer]

On Fri, 2003-06-13 at 19:34, Rupesh S wrote:
>
> I work with FADS823 board running PPC-Linux.
> Now that I plan to put a X-Engine over my Video Controller inbuilt in MPC823
> and supported by FADS board.
> Need help in selecting the X-Engine and the feasibility of the same with the
> above mentioned board.
> Also I would like to know if I can get any ind of reference for the same....

By 'X engine' do you mean an X server? If so, the easiest way might be
to get a framebuffer device going and use an X server on top of that.


--
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer


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

Re: pismo upgraded to 750fx not detected correctly

[Terry Greeniaus]

On Thu, 12 Jun 2003, Chris Studholme wrote:

> I have a Powerbook G3 (Pismo) 400MHz that I've been running Linux on for
> almost 3 years now.  It has been working great, but to ensure that it
> continues to serve me well, I purchased the Powerlogix BlueChip G3 900MHz
> upgrade <http://www.powerlogix.com/products2/bcg3pismo/index.html>.  The
> machine still runs Linux ok, but I have a few problems.
>
> First off, the new processor is an IBM 750FX, but it is recognized as a
> 740/750.
>
>   $ cat /proc/cpuinfo
>   cpu             : 740/750
>   temperature     : 20 C (uncalibrated)
>   clock           : 550MHz
>   revision        : 2.2 (pvr 0008 0202)
>   bogomips        : 1795.68
>   machine         : PowerBook3,1
>   motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
>   detected as     : 70 (PowerBook Pismo)
>   pmac flags      : 00000007
>   L2 cache        : 1024K unified
>   memory          : 256MB
>   pmac-generation : NewWorld
>
> I believe pvr should be 7000 0202.  Also, the clock speed is 900MHz, not
> 550MHz.  I have verified, using some numerical cpu bound programs I have,
> that this machine is running at least twice as fast as it did before the
> upgrade.  Also, note that the bogomips value seems to imply the machine is
> actually running at 900MHz.  Finally, the L2 cache is now only 512K, but
> included on the processor die running at 900MHz.

[mega-snip]

The PowerLogix 900 MHz bluechips are 750FX CPUs, however they have been
strapped so that the PVR reports itself as 0x0008nnnn instead of
0x7000nnnn, so that Apple's OpenFirmware can better support them (in
particular, to automatically enable the L2 cache).  The correct way (on
these boards, anyhow) to determine if this is a 750FX is by writing to
the HID1 register and seeing if it changed.  I have a code snippet to do
this if anyone wants it, although it isn't LinuxPPC-specific.  This is
backwards-compatible with normal 750 CPUs, they don't take an exception
if you try to write to the HID1 register.

As for why it is showing up as 1MB L2 cache, I'm not sure except that
the firmware writes to the 750FX L2CR as though it were a 1MB 750 L2
cache, and then Linux may be reading that value back later on.  It's
harmless since those other bits in the 750FX L2CR don't do anything, but
it might be confusing the kernel.

As for why your test program didn't ramp up/down in speed as you changed
the PLL ratio, I don't know, but I didn't look over it very carefully.
These CPUs definitely support it, so you were probably doing something
incorrectly, or maybe the code wasn't allowing it because it thinks it
is a 750 and not a 750FX CPU.

TG


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

Re: pismo upgraded to 750fx not detected correctly

[Chris Studholme]

On Fri, 13 Jun 2003, Terry Greeniaus wrote:

> The PowerLogix 900 MHz bluechips are 750FX CPUs, however they have been
> strapped so that the PVR reports itself as 0x0008nnnn instead of
> 0x7000nnnn, so that Apple's OpenFirmware can better support them (in
> particular, to automatically enable the L2 cache).  The correct way (on
> these boards, anyhow) to determine if this is a 750FX is by writing to
> the HID1 register and seeing if it changed.  I have a code snippet to do
> this if anyone wants it, although it isn't LinuxPPC-specific.  This is
> backwards-compatible with normal 750 CPUs, they don't take an exception
> if you try to write to the HID1 register.

I would like to see the code snippet.  Do you know how the bluechip G4
upgrade for the pismo works?  Is it also reported as 0x0008nnnn?  If so,
how does your code snippet handle that case?

Chris.


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

Re: pismo upgraded to 750fx not detected correctly

[Terry Greeniaus]

On Thu, 19 Jun 2003, Chris Studholme wrote:

> On Fri, 13 Jun 2003, Terry Greeniaus wrote:
>
> > The PowerLogix 900 MHz bluechips are 750FX CPUs, however they have been
> > strapped so that the PVR reports itself as 0x0008nnnn instead of
> > 0x7000nnnn, so that Apple's OpenFirmware can better support them (in
> > particular, to automatically enable the L2 cache).  The correct way (on
> > these boards, anyhow) to determine if this is a 750FX is by writing to
> > the HID1 register and seeing if it changed.  I have a code snippet to do
> > this if anyone wants it, although it isn't LinuxPPC-specific.  This is
> > backwards-compatible with normal 750 CPUs, they don't take an exception
> > if you try to write to the HID1 register.
>
> I would like to see the code snippet.  Do you know how the bluechip G4
> upgrade for the pismo works?  Is it also reported as 0x0008nnnn?  If so,
> how does your code snippet handle that case?

All of the G4 bluechips are either 7400 (in the older models, not
anymore though) or 7410 CPUs strapped normally (PVR = 0x000Cnnnn [7400]
or 0x800Cnnnn [7410]).  Since these are strapped normally, nothing
special needs to be done to handle that case.  Here's the code snippet
we use in our software to determine if you are on a 750 or 750FX:

UInt32 getRealPVR()
{
	UInt32	pvr = getSPR(287);
	UInt32	realPVR = pvr;
	if((pvr & 0xFFFF0000) == 0x00080000)
	{
		// This could be a 750FX strapped as a 750 PVR
		UInt32 hid1 = getHID1();
		if(hid1 & 0x00010000)
		{
			// PLL1 is in use, fiddle with PLL0
			setHID1(hid1 ^ 0x00000200);
			if(getHID1() != hid1)
			{
				// HID1 changed, this is a 750FX
				realPVR = (0x70000000 |
					(pvr & 0x0000FFFF));
				setHID1(hid1);
			}
		}
		else
		{
			// PLL0 is in use, fiddle with PLL1
			setHID1(hid1 ^ 0x00000002);
			if(getHID1() != hid1)
			{
				// HID1 changed, this is a 750FX
				realPVR = (0x70000000 |
					(pvr & 0x0000FFFF));
				setHID1(hid1);
			}
		}
	}
	return realPVR;
}

Basically this just checks to see if we have a 750 PVR, and if we do it
tries writing to the PLL bits of the PLL that isn't in use in HID1.  If
HID1 changes, then we have a 750FX rather than a 750.  Finally, we reset
HID1 back to whatever it was before we changed it.

This is a bit annoying because it means you can't always rely on a mfpvr
instruction in some assembly code.  We run this routine once when our
software starts up and store the result in a global variable which we
use in the rest of the code.  Also, note that the lower 16 bits of the
PVR remain unchanged regardless of how the CPU is strapped, so we mask
off the top 16 bits only and replace them with 0x7000nnnn.

BTW I am only subscribed to the list digest, so if you want more timely
replies (i.e. more than once a day :P ) CC me with the list message.

TG


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

Re: pismo upgraded to 750fx not detected correctly

[Chris Studholme]

Terry,

Thanks for the code snippet and all the info.  I hope to add this check
immediately after the device-tree is copied to ram and then I'll modify
the in ram version to reflect the properties of a 750fx.  I'll post a
patch here when I get something working.

Chris.


On Fri, 20 Jun 2003, Terry Greeniaus wrote:

>
> On Thu, 19 Jun 2003, Chris Studholme wrote:
>
> > On Fri, 13 Jun 2003, Terry Greeniaus wrote:
> >
> > > The PowerLogix 900 MHz bluechips are 750FX CPUs, however they have been
> > > strapped so that the PVR reports itself as 0x0008nnnn instead of
> > > 0x7000nnnn, so that Apple's OpenFirmware can better support them (in
> > > particular, to automatically enable the L2 cache).  The correct way (on
> > > these boards, anyhow) to determine if this is a 750FX is by writing to
> > > the HID1 register and seeing if it changed.  I have a code snippet to do
> > > this if anyone wants it, although it isn't LinuxPPC-specific.  This is
> > > backwards-compatible with normal 750 CPUs, they don't take an exception
> > > if you try to write to the HID1 register.
> >
> > I would like to see the code snippet.  Do you know how the bluechip G4
> > upgrade for the pismo works?  Is it also reported as 0x0008nnnn?  If so,
> > how does your code snippet handle that case?
>
> All of the G4 bluechips are either 7400 (in the older models, not
> anymore though) or 7410 CPUs strapped normally (PVR = 0x000Cnnnn [7400]
> or 0x800Cnnnn [7410]).  Since these are strapped normally, nothing
> special needs to be done to handle that case.  Here's the code snippet
> we use in our software to determine if you are on a 750 or 750FX:
>
> UInt32 getRealPVR()
> {
> 	UInt32	pvr = getSPR(287);
> 	UInt32	realPVR = pvr;
> 	if((pvr & 0xFFFF0000) == 0x00080000)
> 	{
> 		// This could be a 750FX strapped as a 750 PVR
> 		UInt32 hid1 = getHID1();
> 		if(hid1 & 0x00010000)
> 		{
> 			// PLL1 is in use, fiddle with PLL0
> 			setHID1(hid1 ^ 0x00000200);
> 			if(getHID1() != hid1)
> 			{
> 				// HID1 changed, this is a 750FX
> 				realPVR = (0x70000000 |
> 					(pvr & 0x0000FFFF));
> 				setHID1(hid1);
> 			}
> 		}
> 		else
> 		{
> 			// PLL0 is in use, fiddle with PLL1
> 			setHID1(hid1 ^ 0x00000002);
> 			if(getHID1() != hid1)
> 			{
> 				// HID1 changed, this is a 750FX
> 				realPVR = (0x70000000 |
> 					(pvr & 0x0000FFFF));
> 				setHID1(hid1);
> 			}
> 		}
> 	}
> 	return realPVR;
> }
>
> Basically this just checks to see if we have a 750 PVR, and if we do it
> tries writing to the PLL bits of the PLL that isn't in use in HID1.  If
> HID1 changes, then we have a 750FX rather than a 750.  Finally, we reset
> HID1 back to whatever it was before we changed it.
>
> This is a bit annoying because it means you can't always rely on a mfpvr
> instruction in some assembly code.  We run this routine once when our
> software starts up and store the result in a global variable which we
> use in the rest of the code.  Also, note that the lower 16 bits of the
> PVR remain unchanged regardless of how the CPU is strapped, so we mask
> off the top 16 bits only and replace them with 0x7000nnnn.
>
> BTW I am only subscribed to the list digest, so if you want more timely
> replies (i.e. more than once a day :P ) CC me with the list message.
>
> TG
>
>
>


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

Re: pismo upgraded to 750fx not detected correctly

[Benjamin Herrenschmidt]

On Sat, 2003-06-21 at 17:58, Chris Studholme wrote:
> Terry,
>
> Thanks for the code snippet and all the info.  I hope to add this check
> immediately after the device-tree is copied to ram and then I'll modify
> the in ram version to reflect the properties of a 750fx.  I'll post a
> patch here when I get something working.

Note that the kernel doesn't use the device tree to detect the
CPU type. It rather runs the PVR through a table in
arch/ppc/kernel/cputable.c. There is currently no hook you could
use to 'fix' that. Ideally, you should make sure the CPU is properly
detected before the fixups are done or you may "lose" some 750fx
specific code.

Terry: do you setup PLL1 ? I assume it's set to a low freq by
the firmware and switch to it during idle among others...

If PLL1 isn't set, you should probably not set powersave_lowspeed
in arch/ppc/platforms/pmac_feature.c.

Ben.


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

Re: pismo upgraded to 750fx not detected correctly

[Terry Greeniaus]

On 22 Jun 2003, Benjamin Herrenschmidt wrote:

> Note that the kernel doesn't use the device tree to detect the
> CPU type. It rather runs the PVR through a table in
> arch/ppc/kernel/cputable.c. There is currently no hook you could
> use to 'fix' that. Ideally, you should make sure the CPU is properly
> detected before the fixups are done or you may "lose" some 750fx
> specific code.
>
> Terry: do you setup PLL1 ? I assume it's set to a low freq by
> the firmware and switch to it during idle among others...
>
> If PLL1 isn't set, you should probably not set powersave_lowspeed
> in arch/ppc/platforms/pmac_feature.c.

Currently we don't ship any LinuxPPC software with the upgrades.  The
hardware is strapped so that its built-in PLL comes up at the maximum
speed of the upgrade (usually 900 MHz).  This allows software to
determine the range of allowed PLL settings.  The user can attempt to
overclock by running the software in "advanced" mode, but that isn't
documented or supported really.  The software we ship allows the user to
manually configure the CPU speed by switching the PLLs, if that's what
you're asking I can post some code to do that, but I thought LinuxPPC
already had something similar.  We don't downclock the CPU when it is
idle, but that would probably be a nice power saver.

TG


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

Re: pismo upgraded to 750fx not detected correctly

[Benjamin Herrenschmidt]

>
> Currently we don't ship any LinuxPPC software with the upgrades.  The
> hardware is strapped so that its built-in PLL comes up at the maximum
> speed of the upgrade (usually 900 MHz).  This allows software to
> determine the range of allowed PLL settings.  The user can attempt to
> overclock by running the software in "advanced" mode, but that isn't
> documented or supported really.  The software we ship allows the user to
> manually configure the CPU speed by switching the PLLs, if that's what
> you're asking I can post some code to do that, but I thought LinuxPPC
> already had something similar.  We don't downclock the CPU when it is
> idle, but that would probably be a nice power saver.

We do have code to switch between PLL0 and PLL1, but that code assumes
that PLL1 was already set to an arbitrary "low speed", typically 400Mhz,
by the firmware (we could also lower the core voltage when switching
to low speed on some ibooks but I haven't implemented that yet).

So unless we have some code to detect that PLL1 isn't initialized and
then set it up properly, the user should disable that powersave_lowspeed
code or the kernel will try to switch to PLL1

Ben


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

Re: pismo upgraded to 750fx not detected correctly

[Chris Studholme]

On Sun, 22 Jun 2003, Benjamin Herrenschmidt wrote:
> Note that the kernel doesn't use the device tree to detect the
> CPU type. It rather runs the PVR through a table in
> arch/ppc/kernel/cputable.c. There is currently no hook you could
> use to 'fix' that. Ideally, you should make sure the CPU is properly
> detected before the fixups are done or you may "lose" some 750fx
> specific code.

Ok, so to properly detect the cpu, I ported Terry's code to assembler and
added it to identify_cpu in arch/ppc/kernel/misc.S.  See the attached diff
below.  This code does the following:

- detects 750FX strapped as 750 in identify_cpu
- stores the real pvr is a new global called 'real_pvr'
- updates the cache and clock_frequency values in the device tree at the
  end of finish_device_tree() in prom.c
- makes use of real_pvr instead of mfspr(PVR) in show_cpuinfo() in setup.c

Note that I currently hardcode the clock frequency to 900MHz (speed of my
pismo).  I'll fix that as soon as I learn how to detect the true processor
speed.

For a complete solution, I believe all that needs to be done is to change
all instances of 'mfspr(PVR)' to 'real_pvr', except the one in prom.c.

Also, I just learned ppc assembler today while doing this so please let me
know if you see a more efficient/eloquent way to do the cpu detection, or
if you find a bug in what I have.  I've only tested this on my upgraded
pismo and it seems to work.  Here's my /proc/cpuinfo now:

  cpu             : 750FX
  temperature     : 18-20 C (uncalibrated)
  clock           : 900MHz
  revision        : 2.2 (pvr 7000 0202)
  bogomips        : 1795.68
  machine         : PowerBook3,1
  motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
  detected as     : 70 (PowerBook Pismo)
  pmac flags      : 0000000f
  L2 cache        : 512K unified
  memory          : 256MB
  pmac-generation : NewWorld

Chris.


diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/cputable.c linux-2.4.21-ac1/arch/ppc/kernel/cputable.c
*** linux-2.4.21-ac1.orig/arch/ppc/kernel/cputable.c	Fri Jun 13 10:51:31 2003
--- linux-2.4.21-ac1/arch/ppc/kernel/cputable.c	Sun Jun 22 21:10:37 2003
***************
*** 18,23 ****
--- 18,25 ----

  struct cpu_spec* cur_cpu_spec[NR_CPUS];

+ unsigned int real_pvr;
+
  extern void __setup_cpu_601(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
  extern void __setup_cpu_603(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
  extern void __setup_cpu_604(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S linux-2.4.21-ac1/arch/ppc/kernel/misc.S
*** linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S	Fri Jun 13 10:51:31 2003
--- linux-2.4.21-ac1/arch/ppc/kernel/misc.S	Sun Jun 22 21:25:32 2003
***************
*** 113,118 ****
--- 113,139 ----
  	addis	r8,r3,cpu_specs@ha
  	addi	r8,r8,cpu_specs@l
  	mfpvr	r7
+
+ /* check for 750fx strapped on as 750 */
+ 	srwi	r6,r7,16
+ 	cmpli	0,r6,8
+ 	bne	1f
+ 	mfspr	r5,0x3F1
+ 	srwi.	r6,r5,17
+ 	bso	2f
+ 	xori	r6,r5,0x0200
+ 	b	3f
+ 2:
+ 	xori	r6,r5,0x0002
+ 3:
+ 	mtspr	0x3F1,r6
+ 	mfspr	r6,0x3F1
+ 	cmplw	0,r5,r6
+ 	beq	1f
+
+ /* pvr is actually 0x7000nnnn, not 0x0008nnnn */
+ 	xoris	r7,r7,0x7008
+
  1:
  	lwz	r5,CPU_SPEC_PVR_MASK(r8)
  	and	r5,r5,r7
***************
*** 127,132 ****
--- 148,158 ----
  	slwi	r4,r4,2
  	sub	r8,r8,r3
  	stwx	r8,r4,r6
+
+ 	addis	r6,r3,real_pvr@ha
+ 	addi	r6,r6,real_pvr@l
+ 	stwx	r7,0,r6
+
  	blr

  /*
diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/prom.c linux-2.4.21-ac1/arch/ppc/kernel/prom.c
*** linux-2.4.21-ac1.orig/arch/ppc/kernel/prom.c	Fri Jun 13 10:51:31 2003
--- linux-2.4.21-ac1/arch/ppc/kernel/prom.c	Sun Jun 22 21:31:14 2003
***************
*** 101,106 ****
--- 101,176 ----
  	rtas(&u, rtas_data);
  }

+ /* Fix device tree for misrepresented 750FX.
+  */
+ static void __init
+ prom_fixup_for_750fx(void)
+ {
+   unsigned int cpufreq;
+   struct device_node *cpunode, *cachenode;
+   u32 *value;
+
+   /* need to calculate this somehow */
+   cpufreq = 900000000;
+
+   /* assume only one CPU */
+   cpunode = find_type_devices("cpu");
+   if (!cpunode)
+     goto out;
+
+   value = (u32*)get_property(cpunode, "cpu-version", NULL);
+   if (!value)
+     goto out;
+   *value = real_pvr;
+
+   value = (u32*)get_property(cpunode, "clock-frequency", NULL);
+   if (!value)
+     goto out;
+   *value = cpufreq;
+
+   /* cache size is really 512kB */
+   value = (u32*)get_property(cpunode, "d-cache-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x00080000 / 0x20;
+
+   value = (u32*)get_property(cpunode, "d-cache-block-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x20;
+
+   value = (u32*)get_property(cpunode, "i-cache-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x00080000 / 0x20;
+
+   value = (u32*)get_property(cpunode, "i-cache-block-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x20;
+
+   cachenode = find_type_devices("cache");
+   if (!cachenode)
+     goto out;
+
+   value = (u32*)get_property(cachenode, "d-cache-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x00080000;
+
+   value = (u32*)get_property(cachenode, "i-cache-size", NULL);
+   if (!value)
+     goto out;
+   *value = 0x00080000;
+
+   value = (u32*)get_property(cachenode, "clock-frequency", NULL);
+   if (!value)
+     goto out;
+   *value = cpufreq;
+
+   out:
+ }
+
  /*
   * finish_device_tree is called once things are running normally
   * (i.e. with text and data mapped to the address they were linked at).
***************
*** 161,166 ****
--- 231,239 ----
  	mem = finish_node(allnodes, mem, NULL, 1, 1);
  	dev_tree_size = mem - (unsigned long) allnodes;
  	klimit = (char *) mem;
+
+ 	if ((PVR_VER(real_pvr)==0x7000) && (PVR_VER(mfspr(PVR))==8))
+ 		prom_fixup_for_750fx();
  }

  static unsigned long __init
diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/setup.c linux-2.4.21-ac1/arch/ppc/kernel/setup.c
*** linux-2.4.21-ac1.orig/arch/ppc/kernel/setup.c	Fri Jun 13 10:51:31 2003
--- linux-2.4.21-ac1/arch/ppc/kernel/setup.c	Sun Jun 22 20:52:25 2003
***************
*** 154,160 ****
  	lpj = cpu_data[i].loops_per_jiffy;
  	seq_printf(m, "processor\t: %lu\n", i);
  #else
! 	pvr = mfspr(PVR);
  	lpj = loops_per_jiffy;
  #endif

--- 154,161 ----
  	lpj = cpu_data[i].loops_per_jiffy;
  	seq_printf(m, "processor\t: %lu\n", i);
  #else
! 	/*pvr = mfspr(PVR);*/
! 	pvr = real_pvr;
  	lpj = loops_per_jiffy;
  #endif

diff -c -r linux-2.4.21-ac1.orig/include/asm-ppc/processor.h linux-2.4.21-ac1/include/asm-ppc/processor.h
*** linux-2.4.21-ac1.orig/include/asm-ppc/processor.h	Fri Jun 13 10:51:38 2003
--- linux-2.4.21-ac1/include/asm-ppc/processor.h	Sun Jun 22 19:28:16 2003
***************
*** 615,620 ****
--- 615,625 ----
  #define _machine 0
  #endif /* CONFIG_ALL_PPC */

+ /* Some machines report incorrect version with mfspr(PVR).  Use this global
+  * instead.
+  */
+ extern unsigned int real_pvr;
+
  struct task_struct;
  void start_thread(struct pt_regs *regs, unsigned long nip, unsigned long sp);
  void release_thread(struct task_struct *);


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

Re: pismo upgraded to 750fx not detected correctly

[Gabriel Paubert]

On Mon, Jun 23, 2003 at 12:47:56AM -0400, Chris Studholme wrote:
>
> On Sun, 22 Jun 2003, Benjamin Herrenschmidt wrote:
> > Note that the kernel doesn't use the device tree to detect the
> > CPU type. It rather runs the PVR through a table in
> > arch/ppc/kernel/cputable.c. There is currently no hook you could
> > use to 'fix' that. Ideally, you should make sure the CPU is properly
> > detected before the fixups are done or you may "lose" some 750fx
> > specific code.
>
> Ok, so to properly detect the cpu, I ported Terry's code to assembler and
> added it to identify_cpu in arch/ppc/kernel/misc.S.  See the attached diff
> below.  This code does the following:
>
> - detects 750FX strapped as 750 in identify_cpu
> - stores the real pvr is a new global called 'real_pvr'
> - updates the cache and clock_frequency values in the device tree at the
>   end of finish_device_tree() in prom.c
> - makes use of real_pvr instead of mfspr(PVR) in show_cpuinfo() in setup.c
>
> Note that I currently hardcode the clock frequency to 900MHz (speed of my
> pismo).  I'll fix that as soon as I learn how to detect the true processor
> speed.
>
> For a complete solution, I believe all that needs to be done is to change
> all instances of 'mfspr(PVR)' to 'real_pvr', except the one in prom.c.
>
> Also, I just learned ppc assembler today while doing this so please let me
> know if you see a more efficient/eloquent way to do the cpu detection, or
> if you find a bug in what I have.  I've only tested this on my upgraded
> pismo and it seems to work.  Here's my /proc/cpuinfo now:
>
>   cpu             : 750FX
>   temperature     : 18-20 C (uncalibrated)
>   clock           : 900MHz
>   revision        : 2.2 (pvr 7000 0202)
>   bogomips        : 1795.68
>   machine         : PowerBook3,1
>   motherboard     : PowerBook3,1 MacRISC2 MacRISC Power Macintosh
>   detected as     : 70 (PowerBook Pismo)
>   pmac flags      : 0000000f
>   L2 cache        : 512K unified
>   memory          : 256MB
>   pmac-generation : NewWorld
>
> Chris.
>
>
> diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/cputable.c linux-2.4.21-ac1/arch/ppc/kernel/cputable.c
> *** linux-2.4.21-ac1.orig/arch/ppc/kernel/cputable.c	Fri Jun 13 10:51:31 2003
> --- linux-2.4.21-ac1/arch/ppc/kernel/cputable.c	Sun Jun 22 21:10:37 2003
> ***************
> *** 18,23 ****
> --- 18,25 ----
>
>   struct cpu_spec* cur_cpu_spec[NR_CPUS];
>
> + unsigned int real_pvr;
> +
>   extern void __setup_cpu_601(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
>   extern void __setup_cpu_603(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
>   extern void __setup_cpu_604(unsigned long offset, int cpu_nr, struct cpu_spec* spec);
> diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S linux-2.4.21-ac1/arch/ppc/kernel/misc.S
> *** linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S	Fri Jun 13 10:51:31 2003
> --- linux-2.4.21-ac1/arch/ppc/kernel/misc.S	Sun Jun 22 21:25:32 2003
> ***************
> *** 113,118 ****
> --- 113,139 ----
>   	addis	r8,r3,cpu_specs@ha
>   	addi	r8,r8,cpu_specs@l
>   	mfpvr	r7
> +
> + /* check for 750fx strapped on as 750 */
> + 	srwi	r6,r7,16
> + 	cmpli	0,r6,8
> + 	bne	1f
> + 	mfspr	r5,0x3F1
> + 	srwi.	r6,r5,17
> + 	bso	2f

Are you sure you want to test the summary overflow bit
in this branch ? This bit is not related to the result
of the preceding srwi. instruction, so this looks
strange to say the least.


> + 	xori	r6,r5,0x0200
> + 	b	3f
> + 2:
> + 	xori	r6,r5,0x0002
> + 3:
> + 	mtspr	0x3F1,r6
> + 	mfspr	r6,0x3F1
> + 	cmplw	0,r5,r6
> + 	beq	1f
> +
> + /* pvr is actually 0x7000nnnn, not 0x0008nnnn */
> + 	xoris	r7,r7,0x7008
> +
>   1:
>   	lwz	r5,CPU_SPEC_PVR_MASK(r8)
>   	and	r5,r5,r7
> ***************
> *** 127,132 ****
> --- 148,158 ----
>   	slwi	r4,r4,2
>   	sub	r8,r8,r3
>   	stwx	r8,r4,r6
> +
> + 	addis	r6,r3,real_pvr@ha
> + 	addi	r6,r6,real_pvr@l
> + 	stwx	r7,0,r6

A bit convoluted no? r3 is supposed to be zero, so
the standard way of performing this is:

	lis r6,real_pvr@ha
	stw r7,real_pvr@l(r6)

> +
>   	blr
>

The rest looks fine, but I can't test it and did not check
the details of the boring C code.

	Regards,
	Gabriel


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

Re: pismo upgraded to 750fx not detected correctly

[Chris Studholme]

On Mon, 23 Jun 2003, Gabriel Paubert wrote:
> > diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S linux-2.4.21-ac1/arch/ppc/kernel/misc.S
> > *** linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S	Fri Jun 13 10:51:31 2003
> > --- linux-2.4.21-ac1/arch/ppc/kernel/misc.S	Sun Jun 22 21:25:32 2003
> > ***************
> > *** 113,118 ****
> > --- 113,139 ----
> >   	addis	r8,r3,cpu_specs@ha
> >   	addi	r8,r8,cpu_specs@l
> >   	mfpvr	r7
> > +
> > + /* check for 750fx strapped on as 750 */
> > + 	srwi	r6,r7,16
> > + 	cmpli	0,r6,8
> > + 	bne	1f
> > + 	mfspr	r5,0x3F1
> > + 	srwi.	r6,r5,17
> > + 	bso	2f
>
> Are you sure you want to test the summary overflow bit
> in this branch ? This bit is not related to the result
> of the preceding srwi. instruction, so this looks
> strange to say the least.

What I was trying to do is test the last bit shifted out by the srwi., but
I still don't know how to do that, so how about this instead:

	mfspr	r5,0x3F1
	andis.	r6,r5,0x0001
	bne	2f

> > + 	xori	r6,r5,0x0200
> > + 	b	3f
> > + 2:
> > + 	xori	r6,r5,0x0002
> > + 3:
> > + 	mtspr	0x3F1,r6
> > + 	mfspr	r6,0x3F1
> > + 	cmplw	0,r5,r6
> > + 	beq	1f
> > +
> > + /* pvr is actually 0x7000nnnn, not 0x0008nnnn */
> > + 	xoris	r7,r7,0x7008
> > +
> >   1:
> >   	lwz	r5,CPU_SPEC_PVR_MASK(r8)
> >   	and	r5,r5,r7
> > ***************
> > *** 127,132 ****
> > --- 148,158 ----
> >   	slwi	r4,r4,2
> >   	sub	r8,r8,r3
> >   	stwx	r8,r4,r6
> > +
> > + 	addis	r6,r3,real_pvr@ha
> > + 	addi	r6,r6,real_pvr@l
> > + 	stwx	r7,0,r6
>
> A bit convoluted no? r3 is supposed to be zero, so
> the standard way of performing this is:
> 	lis r6,real_pvr@ha
> 	stw r7,real_pvr@l(r6)

I believe when this method is called, there is some concern over where
data is.  The method comments are:

  /*
   * identify_cpu,
   * called with r3 = data offset and r4 = CPU number
   * doesn't change r3
   */

and all of the other references to global data involve r3, like:

	addis	r8,r3,cpu_specs@ha
	addi	r8,r8,cpu_specs@l

and

	addis	r6,r3,cur_cpu_spec@ha
	addi	r6,r6,cur_cpu_spec@l
	slwi	r4,r4,2
	sub	r8,r8,r3
	stwx	r8,r4,r6

so I figured I should do the same.  But perhaps I could still simplify my
code with:

	addis	r6,r3,real_pvr@ha
	stwx	r7,real_pvr@l(r6)

> > +
> >   	blr
> >

Chris.


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

Re: pismo upgraded to 750fx not detected correctly

[Gabriel Paubert]

On Mon, Jun 23, 2003 at 01:16:41PM -0400, Chris Studholme wrote:
> On Mon, 23 Jun 2003, Gabriel Paubert wrote:
> > > diff -c -r linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S linux-2.4.21-ac1/arch/ppc/kernel/misc.S
> > > *** linux-2.4.21-ac1.orig/arch/ppc/kernel/misc.S	Fri Jun 13 10:51:31 2003
> > > --- linux-2.4.21-ac1/arch/ppc/kernel/misc.S	Sun Jun 22 21:25:32 2003
> > > ***************
> > > *** 113,118 ****
> > > --- 113,139 ----
> > >   	addis	r8,r3,cpu_specs@ha
> > >   	addi	r8,r8,cpu_specs@l
> > >   	mfpvr	r7
> > > +
> > > + /* check for 750fx strapped on as 750 */
> > > + 	srwi	r6,r7,16
> > > + 	cmpli	0,r6,8
> > > + 	bne	1f
> > > + 	mfspr	r5,0x3F1
> > > + 	srwi.	r6,r5,17
> > > + 	bso	2f
> >
> > Are you sure you want to test the summary overflow bit
> > in this branch ? This bit is not related to the result
> > of the preceding srwi. instruction, so this looks
> > strange to say the least.
>
> What I was trying to do is test the last bit shifted out by the srwi., but
> I still don't know how to do that, so how about this instead:
>
> 	mfspr	r5,0x3F1
> 	andis.	r6,r5,0x0001
> 	bne	2f

This looks much better, and is the standard way
of testing a bit on PPC.

> > >   	slwi	r4,r4,2
> > >   	sub	r8,r8,r3
> > >   	stwx	r8,r4,r6
> > > +
> > > + 	addis	r6,r3,real_pvr@ha
> > > + 	addi	r6,r6,real_pvr@l
> > > + 	stwx	r7,0,r6
> >
> > A bit convoluted no? r3 is supposed to be zero, so

Argh, disregard this. I've been lately working too much with
an assembler in which the result is the last operand and
believed that sub r8,r8,r3 was a convoluted way of clearung r3.

> > the standard way of performing this is:
> > 	lis r6,real_pvr@ha
> > 	stw r7,real_pvr@l(r6)
>
> I believe when this method is called, there is some concern over where
> data is.  The method comments are:
>
>   /*
>    * identify_cpu,
>    * called with r3 = data offset and r4 = CPU number
>    * doesn't change r3
>    */
>
> and all of the other references to global data involve r3, like:
>
> 	addis	r8,r3,cpu_specs@ha
> 	addi	r8,r8,cpu_specs@l
>
> and
>
> 	addis	r6,r3,cur_cpu_spec@ha
> 	addi	r6,r6,cur_cpu_spec@l
> 	slwi	r4,r4,2
> 	sub	r8,r8,r3
> 	stwx	r8,r4,r6
>
> so I figured I should do the same.  But perhaps I could still simplify my
> code with:
>
> 	addis	r6,r3,real_pvr@ha
> 	stwx	r7,real_pvr@l(r6)

Correct, provided the last instruction is stw instead of stwx, and
unless I miss again something.

	Gabriel

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

Re: pismo upgraded to 750fx not detected correctly

[Benjamin Herrenschmidt]

> > ***************
> > *** 127,132 ****
> > --- 148,158 ----
> >   	slwi	r4,r4,2
> >   	sub	r8,r8,r3
> >   	stwx	r8,r4,r6
> > +
> > + 	addis	r6,r3,real_pvr@ha
> > + 	addi	r6,r6,real_pvr@l
> > + 	stwx	r7,0,r6
>
> A bit convoluted no? r3 is supposed to be zero, so
> the standard way of performing this is:

Well... he may be called while the kernel hasn't been relocated
yet, so he should take r3 into account at this point.


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