BP6FSB ported to Linux
BP6FSB ported to Linux
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
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
You do not have the required permissions to view the files attached to this post.
Last edited by mdutka on Mon Jun 20, 2005 2:02 pm, edited 1 time in total.
I'm not a linux user, but I've got to say - Nice one!
Like BP6.com? Not a member?
Then why the hell not? It's great!
-> BP6.com Membership <-
Then why the hell not? It's great!
-> BP6.com Membership <-
Good stuff there! I downloaded and compiled but got errors:
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.
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
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.
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
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...
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...
mdudka: I did your changes but the strange thing is that make says it cannot see the file!
And here is the output:
Strange indeed. Here you can see how I have changed the code:
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!
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
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
Code: Select all
[root@loki bp6fsb]# grep i2c-dev.h bp6fsb.c
#include <i2c-dev.h>
As for the file attachment, I guess you should be able to remove it and replace it with a new file!
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
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:
FYI: I found 3 different i2c-dev.h files on my system:
I am using the one that comes from /usr/src/linux-2.6.9...
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
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
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
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:
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.
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
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.
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?
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?
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
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.
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.
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!mdutka wrote:Now I must find some tool to measure CPU speed (or write it myself ) and I'll report results.
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
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
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?
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 Xmdutka 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?
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.
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel