Kernel driver `eeprom.o' ======================== Status: Complete and well-tested Supported chips: * Any EEPROM chip in the designated address range Prefix: 'eeprom' Addresses scanned: I2C 0x50 - 0x57 Datasheets: Publicly available from: Atmel (www.atmel.com), Catalyst (www.catsemi.com), Fairchild (www.fairchildsemi.com), Microchip (www.microchip.com), Philips (www.semiconductor.philips.com), Rohm (www.rohm.com), ST (www.st.com), Xicor (www.xicor.com), and others. Chip Size (bits) Address 24C01 1K 0x50 (shadows at 0x51 - 0x57) 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs) 24C02 2K 0x50 - 0x57 24C04 4K 0x50, 0x52, 0x54, 0x56 (additional data at 0x51, 0x53, 0x55, 0x57) 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52, 0x53, 0x55, 0x56, 0x57) 24C16 16K 0x50 (additional data at 0x51 - 0x57) Sony 2K 0x57 Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37 Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37 Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37 Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37 Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37 ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37 Author: Frodo Looijaard and Philip Edelbrock Module Parameters ----------------- * checksum: int Only accept eeproms whose checksum is correct * force: short array (min = 1, max = 48) List of adapter,address pairs to boldly assume to be present * force_eeprom: short array (min = 1, max = 48) List of adapter,address pairs which are unquestionably assumed to contain a `eeprom' chip * ignore: short array (min = 1, max = 48) List of adapter,address pairs not to scan * ignore_range: short array (min = 1, max = 48) List of adapter,start-addr,end-addr triples not to scan * probe: short array (min = 1, max = 48) List of adapter,address pairs to scan additionally * probe_range: short array (min = 1, max = 48) List of adapter,start-addr,end-addr triples to scan additionally Description ----------- This is a simple EEPROM module meant to enable reading the first 256 bytes of an EEPROM (on a SDRAM DIMM for example). However, it will access serial EEPROMs on any I2C adapter. The supported devices are generically called 24Cxx, and are listed above; however the numbering for these industry-standard devices may vary by manufacturer. This module was a programming exercise to get used to the new project organization laid out by Frodo, but it should be at least completely effective for decoding the contents of EEPROMs on DIMMs. DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants. The other devices will not be found on a DIMM because they respond to more than one address. DDC Monitors may contain any device. Often a 24C01, which responds to all 8 addresses, is found. See the 'ddcmon' driver which has specialized /proc entries for DDC monitors. If the eeprom driver is loaded before the ddcmon driver and there is no 'ignore' line in the /etc/sensors.conf file, the eeprom driver will latch onto the DDC monitor eeprom. Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the specification, so it is guess work and far from being complete. The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional software write protect register at 0x30 - 0x37 (0x20 less than the memory location). The chip responds to "write quick" detection at this address but does not respond to byte reads. If this register is present, the lower 128 bytes of the memory array are not write protected. Any byte data write to this address will write protect the memory array permanently, and the device will no longer respond at the 0x30-37 address. The eeprom driver does not support this register. Lacking functionality: * Full support for larger devices (24C04, 24C08, 24C16). These are not typically found on a PC. These devices will appear as separate devices at multiple addresses. * Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512). These devices require two-byte address fields and are not supported. * Enable Writing. Again, no technical reason why not, but making it easy to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy to disable the DIMMs (potentially preventing the computer from booting) until the values are restored somehow. Use: After inserting the module (and any other required smbus/i2c modules), you should have some EEPROM directories in /proc/sys/dev/sensors/ of names such as "eeprom-i2c-0-50". Inside each of these is a series of files which represent 16 bytes blocks from the EEPROM. The data is in decimal (base 10) delimited by spaces. Note: EEPROMs reported are not nessesarily all from DIMMs. Xeon processors, for example, have serial EEPROMs in them connected to the SMBus which will be found by the module. Take care to ignore the output of decode-dimms.pl for these EEPROMs. There is decode-xeon.pl for them. Same applies to Vaio EEPROMs, which have decode-vaio.pl. The driver caches the data from the monitor and only rereads it from the eeprom if the cache is more than 5 minutes old. Decode-dimms.pl --------------- This Perl script attempts to make sense of the first 128 bytes of a SDRAM PC-100 DIMM. Using the 'Serial Presence Detect (SPD)' Spec (Rev1.2a)** from Intel. When finished, it will decode and report all the values defined in the spec. Much of the information is technical timing and interfacing info (probably not all used by the BIOS or clocking IC). Note: During testing, we noticed that many DIMMs have trucated SPD records. I'm not sure if these conform to an old spec, or if the manufacturers are simply just taking shortcuts. But, many DIMMs have all zeros stored past byte 21. I asked an Intel SDRAM tester, Sat Kolli (skolli@smartm.com), about this and this is what he had to say: "[...] Now in terms of SPD contents, you are right that people do all kinds of things. The way to insure that any module works is to look for the most basic information, such as module bank density, number of banks, and device addresses. That will give you the module size and what devices are used. It is very difficult to verify if the module is PC-100, because of inconsistencies between spd data from different manufacturers. You could read the timing information or the special Intel bytes (126 & 127) but I do not know how many program that information. These inconsistencies may be minimized if you or your customers stay with some of the better known manufacturers." (Thanks goes to Sat Kolli for his comments and help.) Use: After inserting the necessary modules, run the script! Notes: The script assumes that Perl can be found at /usr/bin/perl. If different, you will need to adjust the first line of the file accordingly, or else you will get a strange "decode-dimms.pl: no such file or directory" error. Also note that the script assumes that _all_ the eeproms belong to DIMMs, which may not be the case. Decode-vaio.pl -------------- This Perl script looks for a Sony Vaio EEPROM at 0x57. If your system is not a Sony Vaio laptop, you just don't care. If your system is an old Vaio, you probably don't have an EEPROM on it and this script will be useless to you as well. Use: After inserting the necessary modules, run the script! Notes: The script assumes that Perl can be found at /usr/bin/perl. If different, you will need to adjust the first line of the file accordingly, or else you will get a strange "decode-vaio.pl: no such file or directory" error. Decode-edid.pl This Perl script acts as an interface between the eeprom module and parse-edid, which is part of read-edid. Read-edid is a tool for gathering information on VESA PNP monitors. It is somewhat similar to what our ddcmon driver does, except that ddcmon outputs user-oriented data while read-edid generates a a computer oriented configuration file (primarily for XFree86). Read-edid is made of two components, get-edid which retrieves binary data from the monitor, and parse-edid which decodes the data into useful information. Get-edid uses low level functions, and relies on compliance of both the video card and the monitor to some standard (DCC as it is called). It may not work for everyone. On the other hand, some video cards make this information available on an I2C bus and we are able to get it using our eeprom module. That's why we wrote this script that converts the data as exported by our eeprom module into what parse-edid expects from get-edid. That way, users who can't get get-edid to work still have a chance to be able to retrieve the wanted information thanks to the lm_sensors modules and tools. Use: Unload the ddcmon if it was loaded, load the eeprom module instead. Then, run the script. The script will try to figure out on which I2C bus and at which address is the eeprom, but it may fail. In this case, you can pass the parameters to the script. Examples: decode-edid.pl 1 decode-edid.pl 2 0x50 You will find additional details in the script itself. Read-edid is avilable there: http://john.fremlin.de/programs/linux/read-edid/