aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorHans de Goede <j.w.r.degoede@hhs.nl>2006-06-04 14:22:24 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2006-06-22 14:10:34 -0400
commitf2b84bbcebfdbe4855bab532909eef6621999f9f (patch)
tree9e0112af923b56af771708505b69e792c4bc9f2f /Documentation
parentbed730821b74be4c7d135098842219473f7c8f2c (diff)
[PATCH] abituguru: New hardware monitoring driver
New hardware monitoring driver for the Abit uGuru Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/hwmon/abituguru59
-rw-r--r--Documentation/hwmon/abituguru-datasheet312
2 files changed, 371 insertions, 0 deletions
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
new file mode 100644
index 000000000000..69cdb527d58f
--- /dev/null
+++ b/Documentation/hwmon/abituguru
@@ -0,0 +1,59 @@
1Kernel driver abituguru
2=======================
3
4Supported chips:
5 * Abit uGuru (Hardware Monitor part only)
6 Prefix: 'abituguru'
7 Addresses scanned: ISA 0x0E0
8 Datasheet: Not available, this driver is based on reverse engineering.
9 A "Datasheet" has been written based on the reverse engineering it
10 should be available in the same dir as this file under the name
11 abituguru-datasheet.
12
13Authors:
14 Hans de Goede <j.w.r.degoede@hhs.nl>,
15 (Initial reverse engineering done by Olle Sandberg
16 <ollebull@gmail.com>)
17
18
19Module Parameters
20-----------------
21
22* force: bool Force detection. Note this parameter only causes the
23 detection to be skipped, if the uGuru can't be read
24 the module initialization (insmod) will still fail.
25* fan_sensors: int Tell the driver how many fan speed sensors there are
26 on your motherboard. Default: 0 (autodetect).
27* pwms: int Tell the driver how many fan speed controls (fan
28 pwms) your motherboard has. Default: 0 (autodetect).
29* verbose: int How verbose should the driver be? (0-3):
30 0 normal output
31 1 + verbose error reporting
32 2 + sensors type probing info\n"
33 3 + retryable error reporting
34 Default: 2 (the driver is still in the testing phase)
35
36Notice if you need any of the first three options above please insmod the
37driver with verbose set to 3 and mail me <j.w.r.degoede@hhs.nl> the output of:
38dmesg | grep abituguru
39
40
41Description
42-----------
43
44This driver supports the hardware monitoring features of the Abit uGuru chip
45found on Abit uGuru featuring motherboards (most modern Abit motherboards).
46
47The uGuru chip in reality is a Winbond W83L950D in disguise (despite Abit
48claiming it is "a new microprocessor designed by the ABIT Engineers").
49Unfortunatly this doesn't help since the W83L950D is a generic
50microcontroller with a custom Abit application running on it.
51
52Despite Abit not releasing any information regarding the uGuru, Olle
53Sandberg <ollebull@gmail.com> has managed to reverse engineer the sensor part
54of the uGuru. Without his work this driver would not have been possible.
55
56Known Issues
57------------
58
59The voltage and frequency control parts of the Abit uGuru are not supported.
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet
new file mode 100644
index 000000000000..aef5a9b36846
--- /dev/null
+++ b/Documentation/hwmon/abituguru-datasheet
@@ -0,0 +1,312 @@
1uGuru datasheet
2===============
3
4First of all, what I know about uGuru is no fact based on any help, hints or
5datasheet from Abit. The data I have got on uGuru have I assembled through
6my weak knowledge in "backwards engineering".
7And just for the record, you may have noticed uGuru isn't a chip developed by
8Abit, as they claim it to be. It's realy just an microprocessor (uC) created by
9Winbond (W83L950D). And no, reading the manual for this specific uC or
10mailing Windbond for help won't give any usefull data about uGuru, as it is
11the program inside the uC that is responding to calls.
12
13Olle Sandberg <ollebull@gmail.com>, 2005-05-25
14
15
16Original version by Olle Sandberg who did the heavy lifting of the initial
17reverse engineering. This version has been almost fully rewritten for clarity
18and extended with write support and info on more databanks, the write support
19is once again reverse engineered by Olle the additional databanks have been
20reverse engineered by me. I would like to express my thanks to Olle, this
21document and the Linux driver could not have been written without his efforts.
22
23Note: because of the lack of specs only the sensors part of the uGuru is
24described here and not the CPU / RAM / etc voltage & frequency control.
25
26Hans de Goede <j.w.r.degoede@hhs.nl>, 28-01-2006
27
28
29Detection
30=========
31
32As far as known the uGuru is always placed at and using the (ISA) I/O-ports
330xE0 and 0xE4, so we don't have to scan any port-range, just check what the two
34ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
35and 0xE4 as DATA because Abit refers to them with these names.
36
37If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
38present. We have to check for two different values at data-port, because
39after a reboot uGuru will hold 0x00 here, but if the driver is removed and
40later on attached again data-port will hold 0x08, more about this later.
41
42After wider testing of the Linux kernel driver some variants of the uGuru have
43turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
44have to test CMD for two different values. On these uGuru's DATA will initally
45hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
46first!
47
48To be really sure an uGuru is present a test read of one or more register
49sets should be done.
50
51
52Reading / Writing
53=================
54
55Addressing
56----------
57
58The uGuru has a number of different addressing levels. The first addressing
59level we will call banks. A bank holds data for one or more sensors. The data
60in a bank for a sensor is one or more bytes large.
61
62The number of bytes is fixed for a given bank, you should always read or write
63that many bytes, reading / writing more will fail, the results when writing
64less then the number of bytes for a given bank are undetermined.
65
66See below for all known bank addresses, numbers of sensors in that bank,
67number of bytes data per sensor and contents/meaning of those bytes.
68
69Although both this document and the kernel driver have kept the sensor
70terminoligy for the addressing within a bank this is not 100% correct, in
71bank 0x24 for example the addressing within the bank selects a PWM output not
72a sensor.
73
74Notice that some banks have both a read and a write address this is how the
75uGuru determines if a read from or a write to the bank is taking place, thus
76when reading you should always use the read address and when writing the
77write address. The write address is always one (1) more then the read address.
78
79
80uGuru ready
81-----------
82
83Before you can read from or write to the uGuru you must first put the uGuru
84in "ready" mode.
85
86To put the uGuru in ready mode first write 0x00 to DATA and then wait for DATA
87to hold 0x09, DATA should read 0x09 within 250 read cycles.
88
89Next CMD _must_ be read and should hold 0xAC, usually CMD will hold 0xAC the
90first read but sometimes it takes a while before CMD holds 0xAC and thus it
91has to be read a number of times (max 50).
92
93After reading CMD, DATA should hold 0x08 which means that the uGuru is ready
94for input. As above DATA will usually hold 0x08 the first read but not always.
95This step can be skipped, but it is undetermined what happens if the uGuru has
96not yet reported 0x08 at DATA and you proceed with writing a bank address.
97
98
99Sending bank and sensor addresses to the uGuru
100----------------------------------------------
101
102First the uGuru must be in "ready" mode as described above, DATA should hold
1030x08 indicating that the uGuru wants input, in this case the bank address.
104
105Next write the bank address to DATA. After the bank address has been written
106wait for to DATA to hold 0x08 again indicating that it wants / is ready for
107more input (max 250 reads).
108
109Once DATA holds 0x08 again write the sensor address to CMD.
110
111
112Reading
113-------
114
115First send the bank and sensor addresses as described above.
116Then for each byte of data you want to read wait for DATA to hold 0x01
117which indicates that the uGuru is ready to be read (max 250 reads) and once
118DATA holds 0x01 read the byte from CMD.
119
120Once all bytes have been read data will hold 0x09, but there is no reason to
121test for this. Notice that the number of bytes is bank address dependent see
122above and below.
123
124After completing a successfull read it is advised to put the uGuru back in
125ready mode, so that it is ready for the next read / write cycle. This way
126if your program / driver is unloaded and later loaded again the detection
127algorithm described above will still work.
128
129
130
131Writing
132-------
133
134First send the bank and sensor addresses as described above.
135Then for each byte of data you want to write wait for DATA to hold 0x00
136which indicates that the uGuru is ready to be written (max 250 reads) and
137once DATA holds 0x00 write the byte to CMD.
138
139Once all bytes have been written wait for DATA to hold 0x01 (max 250 reads)
140don't ask why this is the way it is.
141
142Once DATA holds 0x01 read CMD it should hold 0xAC now.
143
144After completing a successfull write it is advised to put the uGuru back in
145ready mode, so that it is ready for the next read / write cycle. This way
146if your program / driver is unloaded and later loaded again the detection
147algorithm described above will still work.
148
149
150Gotchas
151-------
152
153After wider testing of the Linux kernel driver some variants of the uGuru have
154turned up which do not hold 0x08 at DATA within 250 reads after writing the
155bank address. With these versions this happens quite frequent, using larger
156timeouts doesn't help, they just go offline for a second or 2, doing some
157internal callibration or whatever. Your code should be prepared to handle
158this and in case of no response in this specific case just goto sleep for a
159while and then retry.
160
161
162Address Map
163===========
164
165Bank 0x20 Alarms (R)
166--------------------
167This bank contains 0 sensors, iow the sensor address is ignored (but must be
168written) just use 0. Bank 0x20 contains 3 bytes:
169
170Byte 0:
171This byte holds the alarm flags for sensor 0-7 of Sensor Bank1, with bit 0
172corresponding to sensor 0, 1 to 1, etc.
173
174Byte 1:
175This byte holds the alarm flags for sensor 8-15 of Sensor Bank1, with bit 0
176corresponding to sensor 8, 1 to 9, etc.
177
178Byte 2:
179This byte holds the alarm flags for sensor 0-5 of Sensor Bank2, with bit 0
180corresponding to sensor 0, 1 to 1, etc.
181
182
183Bank 0x21 Sensor Bank1 Values / Readings (R)
184--------------------------------------------
185This bank contains 16 sensors, for each sensor it contains 1 byte.
186So far the following sensors are known to be available on all motherboards:
187Sensor 0 CPU temp
188Sensor 1 SYS temp
189Sensor 3 CPU core volt
190Sensor 4 DDR volt
191Sensor 10 DDR Vtt volt
192Sensor 15 PWM temp
193
194Byte 0:
195This byte holds the reading from the sensor. Sensors in Bank1 can be both
196volt and temp sensors, this is motherboard specific. The uGuru however does
197seem to know (be programmed with) what kindoff sensor is attached see Sensor
198Bank1 Settings description.
199
200Volt sensors use a linear scale, a reading 0 corresponds with 0 volt and a
201reading of 255 with 3494 mV. The sensors for higher voltages however are
202connected through a division circuit. The currently known division circuits
203in use result in ranges of: 0-4361mV, 0-6248mV or 0-14510mV. 3.3 volt sources
204use the 0-4361mV range, 5 volt the 0-6248mV and 12 volt the 0-14510mV .
205
206Temp sensors also use a linear scale, a reading of 0 corresponds with 0 degree
207Celsius and a reading of 255 with a reading of 255 degrees Celsius.
208
209
210Bank 0x22 Sensor Bank1 Settings (R)
211Bank 0x23 Sensor Bank1 Settings (W)
212-----------------------------------
213
214This bank contains 16 sensors, for each sensor it contains 3 bytes. Each
215set of 3 bytes contains the settings for the sensor with the same sensor
216address in Bank 0x21 .
217
218Byte 0:
219Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
220Bit 0: Give an alarm if measured temp is over the warning threshold (RW) *
221Bit 1: Give an alarm if measured volt is over the max threshold (RW) **
222Bit 2: Give an alarm if measured volt is under the min threshold (RW) **
223Bit 3: Beep if alarm (RW)
224Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
225Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
226Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
227Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW)
228 Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
229
230* This bit is only honored/used by the uGuru if a temp sensor is connected
231** This bit is only honored/used by the uGuru if a volt sensor is connected
232Note with some trickery this can be used to find out what kinda sensor is
233detected see the Linux kernel driver for an example with many comments on
234how todo this.
235
236Byte 1:
237Temp sensor: warning threshold (scale as bank 0x21)
238Volt sensor: min threshold (scale as bank 0x21)
239
240Byte 2:
241Temp sensor: shutdown threshold (scale as bank 0x21)
242Volt sensor: max threshold (scale as bank 0x21)
243
244
245Bank 0x24 PWM outputs for FAN's (R)
246Bank 0x25 PWM outputs for FAN's (W)
247-----------------------------------
248
249This bank contains 3 "sensors", for each sensor it contains 5 bytes.
250Sensor 0 usually controls the CPU fan
251Sensor 1 usually controls the NB (or chipset for single chip) fan
252Sensor 2 usually controls the System fan
253
254Byte 0:
255Flag 0x80 to enable control, Fan runs at 100% when disabled.
256low nibble (temp)sensor address at bank 0x21 used for control.
257
258Byte 1:
2590-255 = 0-12v (linear), specify voltage at which fan will rotate when under
260low threshold temp (specified in byte 3)
261
262Byte 2:
2630-255 = 0-12v (linear), specify voltage at which fan will rotate when above
264high threshold temp (specified in byte 4)
265
266Byte 3:
267Low threshold temp (scale as bank 0x21)
268
269byte 4:
270High threshold temp (scale as bank 0x21)
271
272
273Bank 0x26 Sensors Bank2 Values / Readings (R)
274---------------------------------------------
275
276This bank contains 6 sensors (AFAIK), for each sensor it contains 1 byte.
277So far the following sensors are known to be available on all motherboards:
278Sensor 0: CPU fan speed
279Sensor 1: NB (or chipset for single chip) fan speed
280Sensor 2: SYS fan speed
281
282Byte 0:
283This byte holds the reading from the sensor. 0-255 = 0-15300 (linear)
284
285
286Bank 0x27 Sensors Bank2 Settings (R)
287Bank 0x28 Sensors Bank2 Settings (W)
288------------------------------------
289
290This bank contains 6 sensors (AFAIK), for each sensor it contains 2 bytes.
291
292Byte 0:
293Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
294Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
295Bit 3: Beep if alarm (RW)
296Bit 7: Shutdown if alarm persist for more then 4 seconds (RW)
297
298Byte 1:
299min threshold (scale as bank 0x26)
300
301
302Warning for the adventerous
303===========================
304
305A word of caution to those who want to experiment and see if they can figure
306the voltage / clock programming out, I tried reading and only reading banks
3070-0x30 with the reading code used for the sensor banks (0x20-0x28) and this
308resulted in a _permanent_ reprogramming of the voltages, luckily I had the
309sensors part configured so that it would shutdown my system on any out of spec
310voltages which proprably safed my computer (after a reboot I managed to
311immediatly enter the bios and reload the defaults). This probably means that
312the read/write cycle for the non sensor part is different from the sensor part.