SoftFSB OCing 4 Linux (Dev)

[Darth_nVader]

This thread is a place keeper for Laptop/NoteBook Software based OCing Development.

Linux Overclocking

Hey - great! Have you considered adding to the Linux lfsb project's code? I'd like to get Linux overclocking working too. Currently I need to bootup in XP/Win7, run setfsb, then warmboot into Linux to have the faster PLL settings. As long as your SMBUS is enabled on bootup it can be done in the same way that setfsb does it, but we have full C source code.

1/ My 2510P's bios disables SMBUS so I enable it in grub2 bootloader. In grub2 grub.conf. RCBA=FED90001 on the 2510P.

write RCBA+3418 (Function Disable register for SMBUS, want bit 2=0)
write_dword 0xFED93418 0x33c0005

2/ Install i2c driver:

# insmod i2c_dev

3/ Then play with lfsb/i2cdump (from lmsensors package) to write the same data that setfsb does to the 0x69 (ICS PLL). From what I can tell it needs to be written as a 16/32 byte block. Here's 2510P's non overclocked (133Mhz) versus overclocked (166Mhz) setfsb diagnosis window showing an example of data to write.

I got stuck in step 3, so perhaps your expertise can help?

Ok, I'm ready to begin.

What do you mean by step 3?

I assume you're trying to write the values SetFSB does under Linux and at some point your stuck?

[Darth_nVader]

Hmmmmmm...........

Linux$ lfsb
-------------------------------------------------------------
CPU frequency : 1828.09 MHz (estimated)

Geekbench@167Fsb

Linux$ sudo i2cset -y 3 0x69 0x00 0x670d w                   
Linux$ sudo i2cset -y 3 0x69 0x01 0x890d w                   
Linux$ sudo i2cset -y 3 0x69 0x1f 0x570d w                   
Linux$ lfsb                                                  
-------------------------------------------------------------                                      
CPU frequency : 2194.90 MHz (estimated)

Geekbench@200Fsb

[Padmé]

[User Retired 2]

Hmmmmmm...........

CPU frequency : 2194.90 MHz (estimated)[/CODE]

Congratulations on the easiest overclock I've seen in Linux. Mine not so successful. Admittedly probably a unique case. I believe the ICS9LPRS355BGLF might be the *only* TME locked PLL setfsb can program. Writing just the difference as shown below does not shift the PLL into the faster frequency. Only the first i2cset line has been accepted by the PLL. Left: 533->667Mhz registers for TME-locked ICS9LPRS355BGLF PLL

Steps to overclock Linux [work in progress]

This will require the lmsensors package, the i2c-dev driver loaded and your ICHxM SMBUS enabled. If SMBUS has been disabled by your bios which I believe your Tecra A9 does, and my 2510P does too, then must enable it using (1) below.

1 / Identify if SMBUS is enabled and load i2c driver.

$ lspci | grep -i smbus
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
$ modprobe i2c-dev
$ ls /dev/i2c*
/dev/i2c-0

Above: example output when SMBUS 0/31/3 is enabled (bus 0)

$ lspci | grep -i smbus
$ modprobe i2c-dev
$ ls /dev/i2c*
ls: cannot access /dev/i2c*: No such file or directory

Above: example output when SMBUS 0/31/3 is disabled (bus 0)

The SMBUS can be enabled one of the following methods. Note: I incorrectly specified the SMBUS enable/disable bit as bit2 in my previous correspondance. It's bit3.

• sudo /usr/share/doc/lm-sensors/examples/hotplug/unhide_ICH_SMBus [appears to work for up to ICH4M ]
• alter the Function Disable configuration register (RCBA+3418h) to toggle the SMBUS bit to be enabled by the grub2 bootloader prior to Linux booting up. Meaning change the SMBUS Function Disable bit 3 from 1 to 0. Might need to update from legacy grub to grub2 1.97b3 or newer. Karmic Koala (9.10) is being shipped with grub2, hopefully a version with the write_dword ability.
  
  How to find the write_dword line to add? RCBA is stored at 0/31/0 F0-F3h. So can identify the RCBA address with a setpci read as shown below.
  

  $ setpci -s 0:1f.0 f0.l
  fed90001

  On my system I viewed the data at RCBA+3418h (FED93418h) using grub2's pre-boot command line (read_dword 0xFED93418), finding it to be 0x33c000d. It can be done in baredit/hwdirect/rw-everything in Windows but warning: if you had already run setfsb on startup it enables the SMBUS bit. In my case the relevant component is the 0xd on the right side. This 1101b (bit 3:0). So clearly bit 3 is 1 (meaning disable SMBUS). I change it to 0, so that now I have 0101b, which is 0x5. So by adding an entry "write_dword 0xFED93418 0x33c0005" in my Linux menuitems in /boot/grub/grub.conf I can enable the SMBUS

2/ Scan to identify devices on i2c bus. ICS PLL appears as device 0x69

$ i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- 0c -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- 1d -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- 44 -- -- -- -- -- -- -- 4c -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- 61 -- -- 64 -- -- -- -- 69 -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

3/ Attempt overclock using setfsb's diagnosis window as a reference to what bytes to write

$ i2cdump -y 0 0x69 s 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 31 85 fc 33 ff f0 90 11 d0 65 7d 00 0d             1??3.????e}.?

$ i2cdump -y 0 0x69 s 0xd
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: cf 44 ef 2f a0 8f f2 23 00 ce 61 53 d8             ?D?/???#.?aS?

$ i2cset -y 0 0x69 0x00 0x3785 w
$ i2cset -y 0 0x69 0x0D 0x482F w
$ i2cset -y 0 0x69 0x10 0x2FA4 w
$ i2cset -y 0 0x69 0x12 0xF6F2 w
$ i2cset -y 0 0x69 0x14 0x2301 w

$ i2cdump -y 0 0x69 s 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 37 85 fc 33 ff f0 90 11 d0 65 7d 00 0d             7??3.????e}.?

$ i2cdump -y 0 0x69 s 0xd
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: cf 44 ef 2f a0 8f f2 23 00 ce 61 53 d8             ?D?/???#.?aS?

UPDATE: Needs to be a 22-byte SMBUS block write to the PLL. 2510P (ics9lprs355) overclocking working with modified lfsb code to do such a write here.

[Darth_nVader]

Should be easy to add the ICS9LPRS355BGLF to lfsb, it's very modular.

It has a full SMBus 2.0 code base.

I'm learning the proper syntax to write a module for it, I'll see what I can whip up for your ICS.

[moral hazard]

does this work for any linux version?

[Darth_nVader]

does this work for any linux version?

Any one that supports lm-sensors and i2c-tools, kernel's 2.5+.

Really, just about everything under the Sun, Mips, Arm, PPC.........

+ most BSD's.

Nando4, have you checked to see if your SMBus is used as an ACPI Device, it may not be Disabled, try the Module i2c-ec, load it with sensors-detect.

You've got lots of devices on your SMBus, so I assume your DSDT is setting them up as ACPI.

Looks like we'll need to add some code to the ISC9LPRS355.c, for lfsb, to check if TME is 1.

Should be done with a function, then a case statement,.......or it maybe better to add it to the GetFSB function.

int ISC9LPRS355._GetFSB()
{
	int i, file, res;
  unsigned char tme;
  unsigned char fs;
  unsigned int n, m;
	float p;
	unsigned char buf[32];
	
	file = i2c_open();
	if(file < 0) return -1;
	res = i2c_smbus_read_block_data(file, CMD, buf);
	i2c_close();

	if(res < 0) return -1;
        tme = buf[2]
        tme &=0x09
        if(tme == 0) ///Some code we need to write
        else if(tme == 1) ///We go here for Abo's ICS*355 work a round
#ifdef DEBUG
	else
	{
		printf("DEBUG: %i bytes read : ", res);
		for(i=0; i>= 1;
	fs &= 0x0F;
  if(fs == 1 || fs == 5) p = 127.994667;
  else if(fs == 4 || fs == 8 || fs == 9) p = 959.66;
  else p = 191.992;

	n = buf[9];
	n &= 0x7F;

	m = buf[10];
	m >>= 1;
	m &= 0x3F;

	return (int)(p*(float)n/(float)m);
}

[User Retired 2]

On Mon, Nov 2, 2009 at 8:09 AM, abo_setfsb wrote:

Hi Nando-san,

> Do I need to do SMBUS block writes (16/32 bytes at a time?) or does there need to be a certain sequence of data to be written?

SetFSB uses SMBUS block writes (22bytes).

abo

There we have it. 22 bytes block writes are needed.

[Darth_nVader]

There we have it. 22 bytes block writes are needed.

I think lfsb is going to take care of this for us, however I'm having some trouble understanding how to calulate N and M..........

From the ICS9LPRS355 DataSheet:

For PLL1 Byte 13 and 14 ( 0x0D and 0x0E )

0x0D

The decimal representation of M Div (5:0) is equal to reference divider value. Default at power up = latch-in or Byte 0 Rom table.

0x0E

The decimal representation of N Div (9:0) is equal to VCO divider value. Default at power up = latch-in or Byte 0 Rom table.

I don't understand this, can anyone give an example?

[User Retired 2]

I think lfsb is going to take care of this for us, however I'm having some trouble understanding how to calulate N and M..........

From the ICS9LPRS355 DataSheet:

For PLL1 Byte 13 and 14 ( 0x0D and 0x0E )

Got my 2510P's ics9lprs355 PLL overclocked in Linux in the simplest possible way. lfsb-ics9lprs355.tgz contains ics9lprs355.c, pll.h and a x86 binary, lfsb which adds this PLL support. Yay! No need to boot into Windows, run setfsb, then warm boot into Linux. I used lfsb's ics94215.c and then viewed the setfsb's Diagnosis window to create a ics9lprs355.c . I can confirm the overclock works:

# glxgears
3141 frames in 5.0 seconds = 628.014 FPS
3144 frames in 5.0 seconds = 628.709 FPS
3149 frames in 5.0 seconds = 629.635 FPS
^C
# lfsb -y ics9lprs355 167
-------------------------------------------------------------
CPU frequency : 17.32 MHz (estimated)
PLL ics9lprs355 is supported.
-------------------------------------------------------------
Changing to:
FSB=167 MHz
FSB frequency changed.
-------------------------------------------------------------
CPU frequency : 34.02 MHz (estimated)
FSB=167 MHz
-------------------------------------------------------------
# glxgears
3938 frames in 5.0 seconds = 787.588 FPS
3930 frames in 5.0 seconds = 785.827 FPS
3922 frames in 5.0 seconds = 784.286 FPS

[NOTE: lfsb doesn't calculate the correct FSB ].

How setfsb was used to generate ics9lprs355.c

setfsb was used to set the internal parameters in ics9lprs355.c. This removed the complexity of understanding what registers are doing what, or doing any sort of bitwise calculations. In my case that required:

(i) default smbus block when not overclocked. I used setfsb's 'get fsb' then 'set fsb' without moving the slider to get my TME-workaround 133Mhz mode SMBUS block data from the Diagnosis Window.

(ii) a table, with index entry being the setfsb 'set' frequency and the two smbus block bytes that are altered for that fsb.

Revised i2cset/lfsb

To make such a tool as generic as possible without the need to compile a binary for all the PLLs out there, it would appear that all is a modifed i2cset or lfsb (perhaps a i2cwrite?) that does the 22-byte block write, taking as input a transcribed file of the setfsb's diagnosis window data for the required FSB frequency.

eg i2cwrite 0 0x69 ics9lprs355_166.txt (166Mhz FSB Diagnosis Window data for ics9lprs355 in setfsb)
eg i2cwrite 0 0x69 ics9lprs355_133.txt (133Mhz FSB Diagnosis Window data for ics9lprs355 in setfsb)

Doing it in this way would leverage off the smarts abo puts into setfsb without needing to understand it.