In commit 78ed68308b ("decode-dimms: Decode manufacturing data for
LPDDR3") we said we would handle LPDDR3 the same as DDR3, however it
was actually only done for the manufacturing data. Extend the idea to
the rest of the script.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Add the current maintainer to the mailing list as the contact points
for bug reports. This ensure that the reports will be read by the
right person.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
While the laptop I originally developed decode-vaio on, only had 5 i2c
buses, there could be more on other models, and there are definitely
more on the system I use to test the script (using i2c-stub) these
days. So look for the VAIO EEPROM on up to 32 i2c buses to be on the
safe side.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
There used to be only 1 eeprom driver (named "eeprom") but now
there are 3 and the legacy "eeprom" driver is not the preferred
option. So list all 3 drivers in our documentation to prevent
confusion.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Wolfram Sang <wsa@kernel.org>
Update the list of memory vendors as of June 2020, including 14
renames.
I also added a runtime sanity check on the number of vendors per
page, as it is very easy to get it wrong.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
For all manpages installed on my Debian system, add a BUGS section, so
people can easily find whom to contact.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
The header comment only mentioned the legacy eeprom driver, while the
at24 and ee1004 drivers should be used nowadays.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
We moved away from Subversion long ago, so $Revision$ and $Date$ are
no longer being resolved. Just use the version of i2c-tools itself.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
No information available yet about the contents of the DDR5 SPD
EEPROMs but we can already report the basic memory type.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Because it is DDR memory, transaction rate is twice the actual clock
speed. What the user is interested in is MT/s, and that's the number
we display, so use the right unit.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
When not reading from dump files, print which kernel driver is being
used. This will help spot setup mistakes where the legacy eeprom
driver stole EEPROMs from the ee1004 driver for DDR4 memory.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
If using the wrong driver, or if reading from a truncated dump file,
make sure we don't attempt to use data bytes beyond what is
available. Doing so would spit pages of cryptic warnings to the user,
explicit error messages are much better.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
The cycle time of high-speed memory modules is stored rounded. We
already have a heuristic to un-round it and display the expected
speed for DDR3 modules. Use the same heuristic for DDR4.
For example this will make PC4-17000 memory properly displayed as
operating at 2133 MHz instead of 2132 MHz. As a side effect, this
fixes a bug where the maximum speed wouldn't be listed in section
"Timings at Standard Speeds" if it had been computed incorrectly
due to the rounded cycle time.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Add all the JEDEC-registered manufacturer names added since JEP106AQ.
Signed-off-by: Vincent Palatin <vpalatin@upmem.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Instead of reencoding pre-DDR3 manufacturer codes to DDR3 manufacturer
codes, move the common decoding to a separate function.
git-svn-id: http://lm-sensors.org/svn/i2c-tools/trunk@6297 7894878c-1315-0410-8ee3-d5d059ff63e0
We also need to discard vendor ID 0 and to report "Unknown" if the
vendor is in a page we don't support yet.
Additionally, check that data is present at all for DDR3 modules as we
already do for pre-DDR3 modules.
git-svn-id: http://lm-sensors.org/svn/i2c-tools/trunk@6296 7894878c-1315-0410-8ee3-d5d059ff63e0
Based on a patch from Peter Missel. The meaning of byte 31, bit 1,
was inverted. Also, this bit is only meaningful if the extended
temperature range is supported (bit 0 is set.)
git-svn-id: http://lm-sensors.org/svn/i2c-tools/trunk@6249 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare
Wolfram Sang
Francois Cartegnie
Joakim Tjernlund
Vincent Palatin