BP6FSB ported to Linux

mdutka · Post by **mdutka** » Sat Jun 18, 2005 5:28 am

Hi All,

I've been searching for some BP6FSB alternative for Linux, with no luck. So, I wrote this simple program - it allows reprogramming clock generator chip from Linux, thus allowing changing FSB on the fly.
It is console-only version for now, and works with BP6 only. Requires 'lm_sensors' package to run (well, not whole package, only a few modules

).
Feel free to use and modify it. Any comments are welcome.

Regards, mdutka

InactiveX · Post by **InactiveX** » Sat Jun 18, 2005 11:00 am

I'm not a linux user, but I've got to say - Nice one!

purrkur · Post by **purrkur** » Sat Jun 18, 2005 4:33 pm

Good stuff there! I downloaded and compiled but got errors:

Code: Select all

make
gcc -O2 -o bp6fsb bp6fsb.c
bp6fsb.c: In function `main':
bp6fsb.c:161: error: `I2C_SMBUS_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:161: error: (Each undeclared identifier is reported only once
bp6fsb.c:161: error: for each function it appears in.)
bp6fsb.c:196: error: `I2C_FUNCS' undeclared (first use in this function)
bp6fsb.c:202: error: `I2C_FUNC_SMBUS_READ_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:211: error: `I2C_SLAVE' undeclared (first use in this function)
make: *** [bp6fsb] Error 1

My lmsensors works just fine. I think the problem is the kernel version you are running (2.4 series). I got Debian running on this BP6 with kernel 2.6.9 (about to be upped to the newly released 2.6.12 in the near future).

As you may know, lmsensors changed quite a lot between 2.4 and 2.6. I am not sure if this will play nice on a 2.6 system if you have developed it on 2.4, but I will definitely be your crash test dummy!

You have a Slack user onboard here as well called Phaedrus. Last time we heard from him he had a broken BP6 but with luck he might get it running again. He is running Slack 10.1 IIRC.

Post by **Derek** » Sat Jun 18, 2005 4:43 pm

Stickied

I will add this to the Files Database as well.

mdutka · Post by **mdutka** » Sun Jun 19, 2005 1:28 am

Well, first bug discovered

It seems that it is related to lack of definitions of some constants. These should be defined in 'linux/i2c-dev.h' include file (in fact, they are defined in 'linux/i2c.h', included from 'linux/i2c-dev.h'). As I2C support is built-in in 2.6 series kernel, maybe these files are somewhat different from that for 2.4 series. Strange, though.

I have second BP6 at work, it runs Slackware 10.1 (with 2.6 series kernel) - I will try to compile this code on that machine and look for problems.

EDIT:
It seems that it is not as simple as including 'i2c.h' in code. It seems that proper way to make it working is to use 'i2c-dev.h' file from lm_sensors package, not from kernel tree.
purrkur, please try following:
- copy 'i2c-dev.h' file from lm_sensors-x.y.z/kernel/include dir (I use 2.9.1 package) to dir containing my code
- in bp6fsb.c, exchange '#include <linux/i2c-dev.h>' with '#include "i2c-dev.h" '
- try to make...
As for me, it compiled OK. However, it compiled OK earlier, too

BTW, is there a way to modify file once posted as attachment? It seems that there will be some changes in contents of originally posted tgz...

purrkur · Post by **purrkur** » Sun Jun 19, 2005 6:58 am

mdudka: I did your changes but the strange thing is that make says it cannot see the file!

Code: Select all

[root@loki bp6fsb]# ls -l
total 20
-rw-r--r--  1 davidt davidt   37 Jun 18 11:46 Makefile
-rw-r--r--  1 davidt davidt 1276 Jun 18 12:15 README
-rw-r--r--  1 davidt davidt 6437 Jun 19 13:49 bp6fsb.c
-rw-r--r--  1 davidt davidt 1550 Jun 19 13:48 i2c-dev.h

And here is the output:

Code: Select all

[root@loki bp6fsb]# make
gcc -O2 -o bp6fsb bp6fsb.c
bp6fsb.c:14:21: i2c-dev.h: No such file or directory
bp6fsb.c: In function `main':
bp6fsb.c:161: error: `I2C_SMBUS_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:161: error: (Each undeclared identifier is reported only once
bp6fsb.c:161: error: for each function it appears in.)
bp6fsb.c:196: error: `I2C_FUNCS' undeclared (first use in this function)
bp6fsb.c:202: error: `I2C_FUNC_SMBUS_READ_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:211: error: `I2C_SLAVE' undeclared (first use in this function)
make: *** [bp6fsb] Error 1

Strange indeed. Here you can see how I have changed the code:

Code: Select all

[root@loki bp6fsb]# grep i2c-dev.h bp6fsb.c
#include <i2c-dev.h>

I would love to work on this a bit more right now but I gotta dash. I'll look at it hopefully later on tonight.

As for the file attachment, I guess you should be able to remove it and replace it with a new file!

mdutka · Post by **mdutka** » Sun Jun 19, 2005 7:14 am

purrkur,
there is subtle difference between '#include <i2c-dev.h>' and '#include "i2c-dev.h" ' - first looks for file in standard "include files place" (e.g. /usr/include) and second looks for file in current directory. That's why it does not work, I think. Try to correct it and we'll see

purrkur · Post by **purrkur** » Sun Jun 19, 2005 9:12 am

Ah, yes. I don't know C/C++ and it shows! But I wasn't paying attention either since I was in a hurry....

I have made the change and I get this error now:

Code: Select all

[root@loki bp6fsb]# make
gcc -O2 -o bp6fsb bp6fsb.c
In file included from bp6fsb.c:14:
i2c-dev.h:37: error: field `__user' has incomplete type
i2c-dev.h:37: warning: no semicolon at end of struct or union
i2c-dev.h:37: error: syntax error before '*' token
i2c-dev.h:42: error: field `__user' has incomplete type
i2c-dev.h:42: warning: no semicolon at end of struct or union
i2c-dev.h:42: error: syntax error before '*' token
i2c-dev.h:44: error: syntax error before '}' token
bp6fsb.c: In function `main':
bp6fsb.c:161: error: `I2C_SMBUS_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:161: error: (Each undeclared identifier is reported only once
bp6fsb.c:161: error: for each function it appears in.)
bp6fsb.c:196: error: `I2C_FUNCS' undeclared (first use in this function)
bp6fsb.c:202: error: `I2C_FUNC_SMBUS_READ_BLOCK_DATA' undeclared (first use in this function)
bp6fsb.c:211: error: `I2C_SLAVE' undeclared (first use in this function)
make: *** [bp6fsb] Error 1

FYI: I found 3 different i2c-dev.h files on my system:

Code: Select all

[root@loki bp6fsb]# slocate i2c-dev.h
warning: slocate: warning: database /var/lib/slocate/slocate.db' is more than 8 days old
/usr/src/linux-2.6.9/include/linux/i2c-dev.h
/usr/src/modules/i2c/kernel/i2c-dev.h
/usr/include/linux/i2c-dev.h

I am using the one that comes from /usr/src/linux-2.6.9...

mdutka · Post by **mdutka** » Sun Jun 19, 2005 12:42 pm

Hmm, all 3 of them seem to be related to kernel, and we must use one NOT coming from kernel tree (it is made to work in kernel "context" only, not in userspace progs - it is one of differences between 2.4 and 2.6 kernels)... In fact, the correct one is from 'lm_sensors' package. When you install lm_sensors, it puts some header files into /usr/local/include/linux dir (as for my system). Among others, there is i2c-dev.h file which we must use.

So, there are two ways to make it correctly compile:
- modify Makefile to contain this:

Code: Select all

bp6fsb: bp6fsb.c
        gcc -O2 -I/usr/local/include -o $@ $^
clean:
        rm -f bp6fsb

and return to original #include set in code (#include <linux/i2c-dev.h>
This will work if 'lm_sensors' was installed and put proper files into /usr/local/include/linux dir (but I'm not sure if it copies any files when installed on system with 2.6 kernel)

- OR copy i2c-dev.h file from lm_sensors package tree (lm_sensors-2.9.1/kernel/include dir) to dir with program and leave #include "i2c-dev.h" in code (do not modify Makefile)

I will try to compile this program in work on Slack 10.1 system and see if there will be any problems - but it will be tomorrow.

purrkur · Post by **purrkur** » Sun Jun 19, 2005 3:03 pm

Hoho. I got your program working.

Your first idea does not work at all because I don't have anything in /usr/local/include so I scrapped that idea.

The second idea was better. I know I am running version 2.9.1 of lm-sensors so it was just a matter of checking exactly which header file was the correct one. That was done in a jiffy with dpkg and tar. I then copied that file over to my bp6fsb directory.

I learned that you need more files than just i2c-dev.h because that file is dependent on i2c.h and i2c-id.h. After that I ran make and it produced a schweet binary

I ran a test to increase my fsb to 72MHz (your 03 option) and then I monitored my cpu speed in gkrellm. Sure enough, the speed increased but it turned out unstable. My speed fluctuated between 427MHz and 447MHz. My cpu speed in /proc/cpuinfo remained the same as before as well. I tried a couple of more speeds but I always got this fluctuation in CPU frequency. When I finally went for 92MHz my computer started behaving very strangely and apps started freezing (so did your app actually, I never got the prompt back after doing "-s 17"). Linux didn't crash or anything but the speeds were hitting 680MHz at best so I guess that was what caused the strange behaviour. I had to reset the machine because I never regained control over bp6fsb. But I wouldn't read too much into that because this particular bp6 board I am running is pretty cranky actually. That is why I am not running a pair of overclocked 366's or my 533's that I got here on my desk.

But the fluctuations are not good. Are you seeing something similar?

mdutka · Post by **mdutka** » Mon Jun 20, 2005 4:44 am

Glad to hear that it worked at last

I tried to compile my code on Slack 10.1 and it compiled without messing with header files. Strange, and definitely it need some further testing.

I tried to overclock my home BP6 (with 2 Celli 433s), it ran stable at FSB 85 MHz, giving CPU clock at 550 MHz. However, when I tried the same on my work BP6 (2x400MHz), it locked up - it seems that HD didn't make it

As of frequency fluctuations - currently I don't have any tool to monitor it in real time. Seems that /proc/cpuinfo gives values as discovered by kernel on system start, so they remain constant... I've checked if OC worked by running cpuburn-in for 10 minutes and looking at # of iterations in this time - it definitely rised after OC.

Now I must find some tool to measure CPU speed (or write it myself

) and I'll report results.

purrkur · Post by **purrkur** » Mon Jun 20, 2005 5:34 am

mdutka wrote:Now I must find some tool to measure CPU speed (or write it myself ) and I'll report results.

There is a module for doing this in gkrellm. So install gkrellm and install a plugin called gkx86info or gkrellm-x86info. I think the author wrote it to be able to keep an eye on his cpu speed on his laptop when using battery. Works great!

If Slack doesn't provide this particular plugin then you should be able to find the source on this Debian page:

http://packages.qa.debian.org/g/gkrellm-x86info.html

mdutka · Post by **mdutka** » Mon Jun 20, 2005 6:47 am

Oh, this soft requires X as I understand - and I don't have X on my systems (yet)

I used x86info software instead - it is somewhat old, but works OK. Both my BP6s run at stable frequencies after OC - 2x466->2x550 (FSB 85) and 2x400->2x550 (FSB 92) - no "floating" freqs, either in idle state or under 100% load. Maybe it is indeed your board that fails? Do you observe such fluctuations when not OC'd?

purrkur · Post by **purrkur** » Mon Jun 20, 2005 3:18 pm

mdutka wrote:Oh, this soft requires X as I understand - and I don't have X on my systems (yet)

I used x86info software instead - it is somewhat old, but works OK. Both my BP6s run at stable frequencies after OC - 2x466->2x550 (FSB 85) and 2x400->2x550 (FSB 92) - no "floating" freqs, either in idle state or under 100% load. Maybe it is indeed your board that fails? Do you observe such fluctuations when not OC'd?

OK. No X

I do use x86info as well but I am not sure if it will give you a measured value like the plugin in gkrellm. Anyways, like I said, I wouldn't trust this board with details although it is stable atm. I am going to do some work on my other two boards so I'll keep you informed if they do any better.