SoftFSB OCing 4 Linux (Dev)

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

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?

 

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

Code:

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

Geekbench@167Fsb

Code:

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

 

<style class='Hidden'>Could you repeat the question please</style>

 

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.

Code:

$ 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)

Code:

$ 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.
  
  Code:

  $ 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

Code:

$ 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

Code:

$ 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.

 

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.

 

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.

Code:

int ISC9LPRS355._GetFSB()
{
	int i, file, res;
  [COLOR="Red"]unsigned char tme;[/COLOR]
  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;
       [COLOR="Red"] 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[/COLOR]
#ifdef DEBUG
	else
	{
		printf("DEBUG: %i bytes read : ", res);
		for(i=0; i<res; i++) printf("%02X ", buf[i]);
		printf("\n");
	}
#endif /* DEBUG */

	fs = buf[0];
  fs >>= 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);
}

 

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

Code:

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

Code:

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?

 

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.

 

Cool, I was working on High Precision FSB, i.e. 100-400Mhz.

Are you able to set fsb for your ICS in this way?

Rather, can you:

# lfsb -y ics9lprs355 157 ?

Also, I mucked up somethig:

Code:

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

Should have been:

Code:

tme = buf[9]
        tme &=0x6f
        if(tme == 0) ///Some code we need to write
        else if(tme == 1) ///We go here for Abo's ICS*355 work a round

buf[9] would be Byte09h
tme &=0x6f read bit 6 of buf[] and set the unsigned char tme to that value.

 

lfsb has a table of entries for various frequencies so I just continued that idea. High Precision FSB like setfsb does requires calculations of M/N DIv x, which didn't make much sense from the datasheet. Would be a very nice way of doing it. I can understand why you are asking for some interpretation of that info. The critical info relating to the TME-locked ics9lprs355 is below. All it needs is the TME-enabled 22-byte entry PLL block, then just alter byte 13/14 for your calculated FSB instead of the FSB/byte13/byte14 table below. Perhaps useful to the development of your O/C tool? Any idea on what it shall be called?

FSB/byte13/byte14 (PLL block)

Code:

        { 112, 0x88, 0x71 },
        { 117, 0x88, 0x87 },
        { 125, 0x88, 0xA3 },
        { 133, 0x88, 0xBF },
        { 142, 0x88, 0xDB },
        { 150, 0x88, 0xF7 },
        { 158, 0x48, 0x13 },
        { 167, 0x48, 0x2F },
        { 175, 0x48, 0x4B },
        { 183, 0x48, 0x67 },
        {0}

TME-workaround for ics9prs355: setfsb data provided by "get fsb" "set fsb" at 133/533Mhz FSB

Code:

 unsigned char buf[] = { 0x37, 0x85, 0xFC, 0x33, 0xFF, 0xF0, 0x90, 0x11,\
                         0xD0, 0x65, 0x7D, 0x00, 0x0D, 0x88, 0xBF, 0xEF,\
                         0x2F, 0xA4, 0xF7, 0xF2, 0x23, 0x01 };

 

Ok, that's what I assumed, in this way we could set specific FSB like changing the CPU Frequency Select Table, without changing it.

We'd just need valid values for 100/200/266/333/400Mhz.

Should work for most ICS chips in later NB's.

Should I continue with High Precision?

If no one is looking for that in Linux, I found, I don't have a working ICH8 SMBus driver in the *BSD I run, it would be better use of my time to get that working first.

I can continue with this later if there are people wanting to help and use it.

Glad it was not just me, I can't make heads or tails of that.

I understand that it's a decimal representation I just can't figure Div (5:0) and Div (9:0), What the Hell

Anyway, maybe I'm just reading it wrong, I should just read the Hex found @ 0x0D and convert it to decimal for PPL1's M value, it's those last two bits 6 and 7?

 

High precision would be ideal. I also just saw your comment in the RTM875t-606 thread. Consider that if you got a generic Linux FSB changer to work, the code could be incorporated as a Grub2 bootloader module, like shown here. So the Linux code could be used to set the FSB for Linux, Windows, Hackintosh, amongst others.

As a grub2 module it would set the faster FSB even before the OS has booted. That would mean a faster bootup. Though suspend would reset the PLL back to default values (I have a setfsb/vbs script workaround for Windows). Hibernate would have the faster fsb since it works via the bootloader too.

grub2 is replacing legacy grub in Ubuntu 9.10 (Karmic Koala).

 

Ok, I'll keep working on H.P.

Adding it for GRUB2 would be nice, I use a BootLoader that can do these sort of things too, it's nice to be able to overwrite the Video Bios in RAM, better OverClocking of the Video card VS. Flashing the System Bios on a NoteBook.

Testing Video Bioses became easy.

 

Darth nVader,

I got some info from abo on how to calculate the FSB based on the N Div info. Byte 13 and byte 14 are the bytes that are changed on the ics9lprs355 to alter the FSB.

Code:

On Tue, Nov 3, 2009 at 9:07 PM, abo_setfsb <[email protected]> wrote:

N Div (9:0) = (byte 13 & 0x40)*[COLOR="Red"][COLOR="Red"]8[/COLOR][/COLOR] + (byte 13 & 0x80)*[COLOR="Red"]2[/COLOR] + byte 14

     ----- Original Message -----
     From: abo_setfsb
     To: Nando
     Sent: Tuesday, November 03, 2009 7:03 PM
     Subject: Re: Data blocks required to overclock ICS9LRS355BGLF [ required for Linux ]

     Hi Nando-san,
        
     VCO[MHz] = 14.318 * N Div (9:0) / M Div (5:0)
       N Div (9:0) = (byte 13 & 0x40)*512 + (byte 13 & 0x80)*256 + byte 14
       M Div (5:0) = byte 13 & 0x3F
        
     FSB[MHz] = VCO / CPU Div
       Table 1: CPU Frequency Select Table
       CPU[MHz] : CPU Div
       266.66 : 3
       [COLOR="Red"]133.33 : 6[/COLOR]
       200.00 : 4
       166.66 : 6
       333.33 : 3
       100.00 : 8
       400.00 : 2
     FSB 100.0MHz : Byte 13 = 0x8A , Byte 14 = 0xA3 [ N Div (9:0) = 0x1A3 , M Div (5:0) = 10 , CPU Div = [COLOR="Red"]6[/COLOR] ]
     FSB 200.0MHz : Byte 13 = 0xCA , Byte 14 = 0x46[ N Div (9:0) = 0x346 , M Div (5:0) = 10 , CPU Div = [COLOR="Red"]6[/COLOR] ]
        
     abo

 

Thanks a lot Nando

I have been wondering how those m/n dividers worked.

 

Still not overly clear when I start plugging numbers into a calculator to try to work off. If it makes sense to anyone, I'd really just like a byte13=... | byte14=.. calculation. Also spawned a 2510P specific post INFO: Overclocking the 2510P in Linux with the additional ics9lprs355.c code added. Can be used as a template to add other ICS PLLs. Documentation there might be useful too to setup the system to allow overclocking.

 

I can't seem to make that math work, but I'll plug at it for a while.

About Bootloaders, Grub2 can do basic PhysMem I/O RW, but SMBuses don't reside in this space, so to change Registers you'd need a driver for the SMBus + the Exc. Code.

Seems like a lot of work, when the Harddrive is what limits boot time, just not worth the extra 2 sec. you would gain, if you had highend raid or SSD.

 

I agree with the "additional 2 seconds" point, but the beauty of bootloader overclocking is it would be universal to all underlying operating systems, including ones where a tool like setfsb doesn't exist Eg: Leopard/DOS. Unless they have tools to do a SMBUS PLL write or do they?? I've asked the question about bootloader PLL overclocking on the grub2 mailing list. See what they have to say.

Additional update from abo on the calculation for FSB/byte13/byte14:

 

If we look at lfsb, it has code for SMBus 2.0, but needs i2c-dev-> needs and SMBus driver like i2c_i801->they both need the linux kernel.

I don't think that it is reasonable or wise to try to gain access to the SMBus in a BootLoader, sure it can be done, however you turn your bootloader into a mini OS.

However, if you enumerate your SMBus as an ACPI device in the DSDT of your bios, you can then use ACPI code to R/W to your SMBus, but I believe this may limit to one off code for each Logic Board.

If we look past x86 Bios, EFI or OpenFirmware, these are Modular Mini OSes, that can Load and execute code from the HD, and with EFI it's C.

So, it's not really practical to try with GRUB, but could be done via ACPI and GRUB, I'm just not sure each Logic Board would not need it's own code.

 

Ok, thanks Nando4, that works for me as well.

I made a few changes to your ics9lprs355.c, as my RTM875t-606 needs a few tweaks, I need to make it's own rtmxxx.c, but it's working just fine.

I'm running a Bootloader for *BSD that has some features Grub does not offer, so I'm Chainloading from Grub like so:

Code:

root (hd1)
chainloader +1

HD1 is the Disk and I don't offer it a Partition, so it just reads to MBR and loads my other Bootloader.

Also, for whatever reason, Grub can't seem to find setfsb.mod unless I give the Full $PATH, so if anyone runs into that:

Code:

insmod (hd0,1)/boot/grub/setfsb.mod

Where (hd0,1) is the disk and partition that /boot/grub/setfsb.mod is on.

You can:

Code:

ls (hd0,1)/boot/grub/

To make sure you have the correct disk and partition.

 

Nando4, here is what the RTM875t-606.c looks like, NOTE: It will compile and run, However, setpll ics9lprs355, so some edits still need to be made and merged.

Code:

/*
*  C Implementation: RTM875T-606
*  Note: This file still needs to be Edited/Merged
* Description: RealTek 875T-606 Clock Generator
*
* Author: nando4 - Darth_nVader -forums.notebookreview.com
*
* Modifed from ics94215.c-ics9lprs355.c
* Author: Nikolay Kislitsa <[email protected]>, (C) 2005
*
*
*/
#include "smbus.h"
#ifdef DEBUG
#include <stdio.h>
#endif

typedef struct
{
	unsigned char fsb;
	unsigned char ctrlb;
        unsigned char ctrlb1;
} PLL_t;
#define SMBUS_DEVICE 0x69
#define BYTECOUNT    32
#define CONTROLBYTE  0x11
#define CONTROLBYTE1 0x13
#define CMD 0x00

static int FSBIndex = 0;

static const PLL_t const pll[] =
{
/* Table containing three values
 * FSB, CONTROLBYTE, CONTROLBYTE1
 * Gathered by setting FSB using setfsb, then reviewing the Diagnosis
 * screen to identify what data changed
 */
	{ 100, 0x58, 0x23},
        //{ 117, 0x88, 0x87},
        //{ 125, 0x88, 0xA3},
	{ 133, 0x20, 0x33},
  	//{ 142, 0x88, 0xDB},
        //{ 150, 0x88, 0xF7},
        //{ 158, 0x48, 0x13},
	{ 167, 0xE8, 0x33},
	{ 183, 0x4C, 0x43},
        { 200, 0xB0, 0x43},
	{0}
};
/* If FSB=133, write original TME block data back to PLL */

int ics9lprs355_SetFSB(int fsb)
{
/* default FSB=166.7Mhz table 
 * We need to change 0x00 bit 2 to 1 First(65), then SetFSB changes Bit 1 to 1(67),next we change Byte 0x01 to 0x89, 0x11 and 0x13 are the Clock Values for the FSB, Bytes 0x29 0x30 and 0x31 set some magic so we must change them too. We seem to Only need to write 32 Bytes of Data, the RTM875t-606 has 48 Byte Control Registers, but 0x33-0x48 seem to change
 Correct, so we don't try to deal with them at all.
 */

	int i, res;
	unsigned char buf[] = {0x67, 0x89, 0xFF, 0xFF, 0xFF, 0x00, 0x30, 0x1E,\
                             0x10, 0x25, 0x7D, 0x00, 0x0D, 0x00, 0x00, 0x00,\
                             0x50, 0xE8, 0x20, 0x33, 0x00, 0x00, 0xB6, 0x53,\
                             0x5F, 0x00, 0x22, 0x00, 0x33, 0x32, 0x30, 0x57 };

	if(fsb < 0) return -1;

	for(i=0; pll[i].fsb; i++)
		if(pll[i].fsb == fsb)
		{
			buf[CONTROLBYTE] = pll[i].ctrlb;
			buf[CONTROLBYTE1] = pll[i].ctrlb1;
                        break;
		}
	if(!buf[CONTROLBYTE]) return -1;

        res = smbus_write_block_data(SMBUS_DEVICE, CMD, BYTECOUNT, buf);
             
	if(res < 0) return res;
#ifdef DEBUG
	else printf("DEBUG: %i bytes written : ", BYTECOUNT);
	for(i=0; i<BYTECOUNT; i++) printf("%02X ", buf[i]);
	printf("\n");
#endif /* DEBUG */
	return 0;
}

int ics9lprs355_GetFSB()
{
	int i, res;
        /* Empty 32 byte buffer */
	unsigned char buf[] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                               0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                               0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                               0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};

        res = smbus_read_block_data(SMBUS_DEVICE, CMD, buf);

	if(res < 0) return -1;
#ifdef DEBUG
	else printf("DEBUG: %i bytes read : ", res);
	for(i=0; i<res; i++) printf("%02X ", buf[i]);
	printf("\n");
#endif /* DEBUG */

	for(i=0; pll[i].fsb; i++)
		if(pll[i].ctrlb == buf[CONTROLBYTE]) return pll[i].fsb;

	return -1;
}

int ics9lprs355_CheckFSB(int fsb, float *sdram, float *pci, float *agp)
{
	int i;

	if(sdram) *sdram = -1.0;
	if(pci) *pci = -1.0;
	if(agp) *agp = -1.0;

	if(fsb < 0) return -1;

	for(i=0; pll[i].fsb; i++)
		if(pll[i].fsb == fsb) return 0;
	return -1;
}

int ics9lprs355_GetFirstFSB()
{
	FSBIndex = 0;
  if(pll[FSBIndex].fsb) return pll[FSBIndex].fsb;
  else return -1;
}

int ics9lprs355_GetNextFSB()
{
	FSBIndex++;
	if(pll[FSBIndex].fsb) return pll[FSBIndex].fsb;
	else return -1;
}

View attachment rtm875t-606.txt

If you look at some of the Code Comments, I explain some of the Magic Bits:

0x00 the last/first half Byte will differ for those with 533/800Mhz FSB CPU's (6)<--is of course 667Mhz, and that's what I write to that address, however, as these Bits are RO, it should work for those with 533/800 FSB CPU's. The first/last half Byte should also be set to 7(Have a look at the ics9lprs355 DataSheet for what is done).

0x01 is also Changed to 0x89(Have a look at the ics9lprs355 DataSheet for what is done).

0x11 and 0x13 are the Registers that change the Clock Value of the FSB/DRAM

0x1D, 0x1E, and 0x1F These need to be SetUP Before the Values of 0x11 and 0x13 are Valid/Read, I don't know why, but I don't need to, just write 32 30 57 and it's all good.

I get lockup @100Mhz FSB with setfsb.mod, so 133 is the best safe(underclocked) FSB for me, I also see this in XP SetFSB, sometimes. However sometimes 100Mhz works just fine?

I can't go past 203Mhz without lockup, I think my RAM is to blame, as it only have SDP Timing for 200/266/333 DDR, so if someone with a 800Mhz CPU and/or better RAM can help, we can ADD Values for 200+FSB, as it is now we don't know the Values for 0x11 and 0x13.

 

Also, I have to say, I impressed with Grub2 and Uncle Joe/Nando4's work with adding lfsb/i2c-dev/i801 code. One of many times, I'm happy to be wrong.

One BootLoader to rule them all, One BootLoader to find them, One Bootloader to bring them all..........

 

The PLL chips has TME-locked, and it's still oc in grub2 bootloader?

 

grub2-setfsb just sends PLL config data to the PLL, which you obtain using Windows setfsb Diagnosis window.

This means that if you can't get your PLL to OC in Windows using setfsb, you can't get OC using grub2-setfsb.

 

Hi everyone,
I've bought intels new atom based board D510MO (specs here) and am trying to save some power by checking out the undervolting/underclocking capabilities of that baby.
This thread is the only one i found on the internet where some guys seem to know how that could be done.
First, his box is headless (I just don't have any display to connetct it to), is running a gentoo and will be running 24/7 as my nas/router/backup storage.
Second, I've no experience in diggin into register directly, so please point me to some documentation if you know anything worth reading.

I've read this thread, found the chip on my board, its a ICS 9LPRS525AGLF. Its datasheet is found here.

thats its i2c dump:

Code:

#i2cdump 0 0x69
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
10: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
20: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
30: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
40: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
50: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
60: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
70: 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d    ????????????????
80: 61 d9 fe ff ff 00 00 01 03 25 83 26 0d d3 a5 13    a??....??%?&????
90: 3c 83 1b ff 3e 65 88 87 00 04 cd 5e 01 bc 0f 00    <??.>e??.??^???.
a0: 61 d9 fe ff ff 00 00 01 03 25 83 26 0d d3 a5 13    a??....??%?&????
b0: 3c 83 1b ff 3e 65 88 87 00 04 cd 5e 01 bc 0f 00    <??.>e??.??^???.
c0: 61 d9 fe ff ff 00 00 01 03 25 83 26 0d d3 a5 13    a??....??%?&????
d0: 3c 83 1b ff 3e 65 88 87 00 04 cd 5e 01 bc 0f 00    <??.>e??.??^???.
e0: 61 d9 fe ff ff 00 00 01 03 25 83 26 0d d3 a5 13    a??....??%?&????
f0: 3c 83 1b ff 3e 65 88 87 00 04 cd 5e 01 bc 0f 00    <??.>e??.??^???.

All interesting registers seem to start at 0x80, so any register mentioned in the datasheet is added to 0x80, right?

I can see register 0x89 is at value 0x25, which is 0b00100101, its sixth bit is zero -> TME is off. Is that correct?

The first three bits of register 9 are called "IO Output voltage select", is that the cpu voltage? default is 0.8V, i tried to set it lower, eg to 0.7V by executing

Code:

i2cset 0 0x69 0x89 0x24

the chip seems to accept it, as i2cdump shows the new value, but power consumption of the systems stays the same. I went down to 0x20, which is 0.3V (i hoped the cpu would crash at that low voltage, but it did not), but still it makes no difference in that systems power usage.

Did I miss something? done anything wrong? Will try to manipulate the FSB of the system tomorrow, hopefully that works out...
Are there any bits I should take a look at to save some power?
I imagine writing kind of a cpufreq governor which will check the systems load and clock it higher or lower on demand, setting appropriate voltages, but first I try to understand how that tricky register setting works and what can be done in order to save power vs computing speed and how reliabe this works.
Any help, hints, links are appreciated.

 

Setting byte 9, bit 0-2 from "101" (0.8V) to "000" (0.3V) had no effect on my system's power consumption, nor did it crash the system. Not clear what that I/O voltage is.

To control CPU voltage try phc (processor hardware control). Only problem I believe is that atoms don't have programmable VID to go along with FIDs. I haven't seen anyone report successfully undervolting an atom using rmclock either. If you did save some power it would be negligble in the scheme of things. An atom is already rated at 2.5W TDP. Your I/O chip uses more power.

 

Btw, the Atom D510 is rated at 13W TDP, its chipset 2W...

Today I tried to manipulate FSB, but it didn't work out :/
The specs tell bits 5,6,7 in byte 0 are the ones defining frequencies, but sadly they are read-only. I tried to change the values, but well, they are really read only

Their default value is "Latch", which means, as far as I get it, they allow to write exactly one value and then stay with that as long the system is running.

Is there any way to open this latch and rewrite bits?

I'm stumped at this point, is there anything left I can try to save power?
Hmm, i'll try to disable a core now, maybe this works out, at least.

 

1. If the CPU is socketted, try a CPU pin voltmod as shown here. D510 datasheet has a VID table ranging from 0.7V to 1.2V.

2. Modify core voltage regulator as shown here.

3. Check if your PLL is TME-locked as shown here. Can pinmod it to unlock it so that PLL can be programmed using software. This would allow you to overclock up to whatever your CPU voltage allows. You may have some gains underclocking as well, moreso if can combine with (1) and (2) above.

 

Developing a setfsb successor

NBR member Inteks has used the grub2-setfsb code to come up with a prelim setfsb successor in Windows. See

http://code.google.com/p/setfsb/wiki/Screenshot
http://code.google.com/p/setfsb/source/browse/

Not working as yet but coders welcome to join the project to help it along. AFAIK Abo has stopped development of setfsb based on his last website message so no new PLLs will be supported. This will keep the OC torch alive.

Inteks wrote 1810tray allowing overclocked-AC, undervolted-DC profiles but is now enhancing it for more generic notebook usage. setfsb being an important component.

 

That's good news, hope the RTM875T-606 can be used.

 

Yeah, second that. Is there any current working method that will allow RTM875T-606 PLLs to overclock with 1MHz granularity (eg. not using the hacked version of SetFSB)?

 

Have you made any edits to it since then? It's been a while...

I have a T9300 Penryn (800MHz CPU FSB) so just tell me what I can do to help... I've already unlocked my TME.

 

Hello. I'm trying to alter fsb on ASUS UL20a, Ubuntu10.04 ...
Please help

Here are steps what I do:

1. Ensure SMBUS is not enabled by default

Code:

root@madcat-laptop:~# lspci | grep -i smbus
root@madcat-laptop:~# 

2. do setpci -s 0:1f.0 f0.l

Code:

root@madcat-laptop:~# setpci -s 0:1f.0 f0.l
fed1c001

3. 0xFED1C001 + 0x3418 = 0xFED1F419. In grub console:

Code:

read_dword 0xFED1F418
0x31E0009

4. Disable 3rd bit: 9h = 1001b ; 0001b = 1h

Code:

write_dword 0xFED1F418 0x31E0001

5. Boot up and now SMBUS appeared

Code:

root@madcat-laptop:~# lspci | grep -i smbus
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)

6. Do modprobe and check for i2c buses

Code:

root@madcat-laptop:~# modprobe i2c-dev
root@madcat-laptop:~# ls /dev/i2c*
/dev/i2c-0  /dev/i2c-1  /dev/i2c-2

7. The odd thing that i2c-0 i2c-1 and i2c-2 were present as well as before enabling SMBUS and their output via i2cdetect was the same

Code:

root@madcat-laptop:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@madcat-laptop:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
root@madcat-laptop:~# i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                        

What can be done to find and access PLL ?

 

Hi. Coincidences do happen, and it strikes me that someone somwhere is dealing with a similar problem at the same time....

reflections aside, i have the same problem described by madcat-st, on a samsung netbook running linux mint 9.
SMBUS is detected as intel corproation N10/ICH 7 Family SMBus Controller (rev2)

i2cdetect is not able to detect anything

Thanks!

 

I am trying to make it work on Ubuntu 10.4 x64 but this is what I get

Code:

[FONT=Arial][SIZE=2]stamatisx@stamatisx-laptop:~$ lspci | grep -i smbus
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
stamatisx@stamatisx-laptop:~$ modprobe i2c-dev
stamatisx@stamatisx-laptop:~$ ls /dev/i2c*
ls: cannot access /dev/i2c*: No such file or directory[/SIZE][/FONT]

Any ideas?

Also

Code:

[FONT=Arial]stamatisx@stamatisx-laptop:~/Desktop/grub-1.97_setfsb$ ./configure --disable-werror
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for cmp... cmp
checking for bison... no
configure: error: bison is not found[/FONT]

 

1. Some distributions blacklist the i2c-dev or i2c-i801 module. Check your /etc/modules and uncomment if blacklisted

2. Install the bison package.

 

Code:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

lp
rtc

I don't see anything blacklisted here

Also how do I choose between those two?

Where is the setfsb.mod located?

 

I have installed ubuntu and now I am stuck at step 2:

I get an error "bison not found" or something like that.
Not sure what to do at this point. Where do I get the bison package?

 

apt-get install bison

 

I get this output:

Code:

s@ubuntu:~$ sudo apt-get install bison
[sudo] password for s:
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Package bison is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'bison' has no installation candidate
s@ubuntu:~$ ^C
s@ubuntu:~$

EDIT: I think I almost have it installed.

EDIT#2: problem solved after installing some "m4" thing...

 

New problem, when I used the make command, I got this at the end of the output:

Code:

In file included from /usr/include/features.h:387,
                 from /usr/include/stdint.h:26,
                 from lfsb-0.4.1/setfsb_grub.c:4:
/usr/include/gnu/stubs.h:7: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.
make: *** [lfsb-0.4.1/setfsb_grub.o] Error 1
s@ubuntu:~/grub-1.97_setfsb$ ^C
s@ubuntu:~/grub-1.97_setfsb$

Am I missing something?

EDIT: problem solved. I downloaded glibc-devel-2.6-4.0.120asp.i386.rpm and copied a file called stubs-32.h to /usr/include/gnu.