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