Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
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 really 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 useful 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 initially 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 than 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 successful 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 successful 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 than 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 than 4 seconds (RW) 297 298 Byte 1: 299 min threshold (scale as bank 0x26) 300 301 302 Warning for the adventurous 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 immediately 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.