]>
Commit | Line | Data |
---|---|---|
f2b84bbc HG |
1 | 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 <ollebull@gmail.com>, 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 <j.w.r.degoede@hhs.nl>, 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. |