Change log:
decode-dimms: Actually decode LPDDR3 modules
In commit 78ed68308b58 ("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.
Upstream changes. (Note that some of these don't really affect to NetBSD,
but are included anyway for reducing differences with the upstream copy.)
Detect and report truncated input files
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.
Print kernel driver used
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.
Print DDR memory speed in MT/s not MHz
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.
Add DDR5 memory types to the list
No information available yet about the contents of the DDR5 SPD
EEPROMs but we can already report the basic memory type.
Decode manufacturing data for LPDDR3
I assume the manufacturing data format for LPDDR3 is the same
as regular DDR3.
Fix the version string
We moved away from Subversion long ago, so $Revision$ and $Date$
are no longer being resolved. Just use the version of i2c-tools
itself.
Point the user to the right driversHEADmaster
The header comment only mentioned the legacy eeprom driver, while
the at24 and ee1004 drivers should be used nowadays.
Changes from upstream:
Round DDR4 speed properly
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.
Edit the tool to have a useful version identifier - avoiding any
attempts for repository-management tools to perform substitution on
$Revision$ and $Date$
