Revision 3007, 9.4 KB (checked in by khali, 10 years ago)

Backport the cleanups and corrections Rudolf Marek and I did when
porting the chips documentation to Linux 2.6.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
1Kernel driver `eeprom.o'
4Status: Complete and well-tested
6Supported chips:
7  * Any EEPROM chip in the designated address range
8    Prefix: 'eeprom'
9    Addresses scanned: I2C 0x50 - 0x57
10    Datasheets: Publicly available from:
11                Atmel (,
12                Catalyst (,
13                Fairchild (,
14                Microchip (,
15                Philips (,
16                Rohm (,
17                ST (,       
18                Xicor (,         
19                and others.
21        Chip     Size (bits)    Address
22        24C01     1K            0x50 (shadows at 0x51 - 0x57)
23        24C01A    1K            0x50 - 0x57 (Typical device on DIMMs)
24        24C02     2K            0x50 - 0x57
25        24C04     4K            0x50, 0x52, 0x54, 0x56
26                                (additional data at 0x51, 0x53, 0x55, 0x57)
27        24C08     8K            0x50, 0x54 (additional data at 0x51, 0x52,
28                                0x53, 0x55, 0x56, 0x57)
29        24C16    16K            0x50 (additional data at 0x51 - 0x57)
30        Sony      2K            0x57
32        Atmel     34C02B  2K    0x50 - 0x57, SW write protect at 0x30-37
33        Catalyst  34FC02  2K    0x50 - 0x57, SW write protect at 0x30-37
34        Catalyst  34RC02  2K    0x50 - 0x57, SW write protect at 0x30-37
35        Fairchild 34W02   2K    0x50 - 0x57, SW write protect at 0x30-37
36        Microchip 24AA52  2K    0x50 - 0x57, SW write protect at 0x30-37
37        ST        M34C02  2K    0x50 - 0x57, SW write protect at 0x30-37
40Author: Frodo Looijaard <> and Philip Edelbrock
41        <>
44Module Parameters
47* checksum: int
48  Only accept eeproms whose checksum is correct
49* force: short array (min = 1, max = 48)
50  List of adapter,address pairs to boldly assume to be present
51* force_eeprom: short array (min = 1, max = 48)
52  List of adapter,address pairs which are unquestionably assumed to contain
53  a `eeprom' chip
54* ignore: short array (min = 1, max = 48)
55  List of adapter,address pairs not to scan
56* ignore_range: short array (min = 1, max = 48)
57  List of adapter,start-addr,end-addr triples not to scan
58* probe: short array (min = 1, max = 48)
59  List of adapter,address pairs to scan additionally
60* probe_range: short array (min = 1, max = 48)
61  List of adapter,start-addr,end-addr triples to scan additionally
67This is a simple EEPROM module meant to enable reading the first 256 bytes
68of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
69EEPROMs on any I2C adapter. The supported devices are generically
70called 24Cxx, and are listed above; however the numbering
71for these industry-standard devices may vary by manufacturer.
73This module was a programming exercise to get used to the new project
74organization laid out by Frodo, but it should be at least completely
75effective for decoding the contents of EEPROMs on DIMMs.
77DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
78The other devices will not be found on a DIMM because
79they respond to more than one address.
81DDC Monitors may contain any device. Often a 24C01, which responds
82to all 8 addresses, is found. See the 'ddcmon' driver which has
83specialized /proc entries for DDC monitors. If the eeprom driver is
84loaded before the ddcmon driver and there is no 'ignore' line in the
85/etc/sensors.conf file, the eeprom driver will latch onto the DDC monitor
88Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
89specification, so it is guess work and far from being complete.
91The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
92software write protect register at 0x30 - 0x37 (0x20 less than the
93memory location). The chip responds to "write quick" detection at this
94address but does not respond to byte reads.
95If this register is present, the lower 128 bytes of the memory
96array are not write protected. Any byte data write to this address
97will write protect the memory array permanently, and the device
98will no longer respond at the 0x30-37 address.
99The eeprom driver does not support this register.
101Lacking functionality:
103* Full support for larger devices (24C04, 24C08, 24C16). These are
104not typically found on a PC. These devices will appear as separate
105devices at multiple addresses.
107* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
108These devices require two-byte address fields and are not supported.
110* Enable Writing.  Again, no technical reason why not, but making it easy
111to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
112to disable the DIMMs (potentially preventing the computer from booting)
113until the values are restored somehow.
118After inserting the module (and any other required smbus/i2c modules), you
119should have some EEPROM directories in /proc/sys/dev/sensors/ of names such
120as "eeprom-i2c-0-50".  Inside each of these is a series of files which
121represent 16 bytes blocks from the EEPROM.  The data is in decimal (base
12210) delimited by spaces.
126EEPROMs reported are not nessesarily all from DIMMs.  Xeon processors, for
127example, have serial EEPROMs in them connected to the SMBus which will be
128found by the module.  Take care to ignore the output of for
129these EEPROMs.  There is for them.  Same applies to Vaio
130EEPROMs, which have
132The driver caches the data from the monitor and only rereads it
133from the eeprom if the cache is more than 5 minutes old.
139This Perl script attempts to make sense of the first 128 bytes of a SDRAM
140PC-100 DIMM.  Using the 'Serial Presence Detect (SPD)' Spec (Rev1.2a)** from
141Intel.  When finished, it will decode and report all the values defined in
142the spec.  Much of the information is technical timing and interfacing info
143(probably not all used by the BIOS or clocking IC).
145Note: During testing, we noticed that many DIMMs have trucated SPD records.
146I'm not sure if these conform to an old spec, or if the manufacturers are
147simply just taking shortcuts.  But, many DIMMs have all zeros stored past
148byte 21.  I asked an Intel SDRAM tester, Sat Kolli (,
149about this and this is what he had to say:
151"[...] Now in terms of SPD contents, you are right that people do all kinds
152of things. The way to insure that any module works is to look for the most
153basic information, such as module bank density, number of banks, and device
154addresses. That will give you the module size and what devices are used. It
155is very difficult to verify if the module is PC-100, because of
156inconsistencies between spd data from different manufacturers. You could
157read the timing information or the special Intel bytes (126 & 127) but I do
158not know how many program that information. These inconsistencies may be
159minimized if you or your customers stay with some of the better known
160manufacturers."  (Thanks goes to Sat Kolli for his comments and help.)
164After inserting the necessary modules, run the script!
168The script assumes that Perl can be found at /usr/bin/perl.  If different,
169you will need to adjust the first line of the file accordingly, or else
170you will get a strange " no such file or directory" error.
172Also note that the script assumes that _all_ the eeproms belong to DIMMs,
173which may not be the case.
179This Perl script looks for a Sony Vaio EEPROM at 0x57. If your system is not
180a Sony Vaio laptop, you just don't care. If your system is an old Vaio, you
181probably don't have an EEPROM on it and this script will be useless to you
182as well.
186After inserting the necessary modules, run the script!
190The script assumes that Perl can be found at /usr/bin/perl.  If different,
191you will need to adjust the first line of the file accordingly, or else
192you will get a strange " no such file or directory" error.
197This Perl script acts as an interface between the eeprom module and
198parse-edid, which is part of read-edid. Read-edid is a tool for gathering
199information on VESA PNP monitors. It is somewhat similar to what our
200ddcmon driver does, except that ddcmon outputs user-oriented data while
201read-edid generates a a computer oriented configuration file (primarily
202for XFree86).
204Read-edid is made of two components, get-edid which retrieves binary data
205from the monitor, and parse-edid which decodes the data into useful
206information. Get-edid uses low level functions, and relies on compliance
207of both the video card and the monitor to some standard (DCC as it is
208called). It may not work for everyone. On the other hand, some video
209cards make this information available on an I2C bus and we are able to
210get it using our eeprom module. That's why we wrote this script that
211converts the data as exported by our eeprom module into what parse-edid
212expects from get-edid. That way, users who can't get get-edid to work
213still have a chance to be able to retrieve the wanted information thanks
214to the lm_sensors modules and tools.
218Unload the ddcmon if it was loaded, load the eeprom module instead. Then,
219run the script. The script will try to figure out on which I2C bus and at
220which address is the eeprom, but it may fail. In this case, you can pass
221the parameters to the script. Examples:
223 1
224 2 0x50
226You will find additional details in the script itself. Read-edid is avilable
Note: See TracBrowser for help on using the browser.