Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

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