About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / hwmon / abituguru-datasheet




Custom Search

Based on kernel version 3.16. Page generated on 2014-08-06 21:39 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.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.