inxi
inxi copied to clipboard
smxi
Add detailed information about RAM modules
Hi.
I want suggest new feature - detailed information about RAM modules. Information like this
---=== Memory Characteristics ===---
Maximum module speed 1333 MHz (PC3-10600)
Size 8192 MB
Banks x Rows x Columns x Bits 8 x 16 x 10 x 64
Ranks 2
SDRAM Device Width 8 bits
Bus Width Extension 0 bits
tCL-tRCD-tRP-tRAS 9-9-9-24
Supported CAS Latencies (tCL) 9T, 8T, 7T, 6T
---=== Timings at Standard Speeds ===---
tCL-tRCD-tRP-tRAS as DDR3-1333 9-9-9-24
tCL-tRCD-tRP-tRAS as DDR3-1066 7-7-7-20
tCL-tRCD-tRP-tRAS as DDR3-800 6-6-6-15
---=== Timing Parameters ===---
Minimum Cycle Time (tCK) 1.500 ns
Minimum CAS Latency Time (tAA) 13.125 ns
Minimum Write Recovery time (tWR) 15.000 ns
Minimum RAS# to CAS# Delay (tRCD) 13.125 ns
Minimum Row Active to Row Active Delay (tRRD) 6.000 ns
Minimum Row Precharge Delay (tRP) 13.125 ns
Minimum Active to Precharge Delay (tRAS) 36.000 ns
Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns
Minimum Recovery Delay (tRFC) 260.000 ns
Minimum Write to Read CMD Delay (tWTR) 7.500 ns
Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns
Minimum Four Activate Window Delay (tFAW) 30.000 ns
---=== Optional Features ===---
Operable voltages 1.5V
RZQ/6 supported? Yes
RZQ/7 supported? Yes
DLL-Off Mode supported? Yes
Operating temperature range 0-95 degrees C
Refresh Rate in extended temp range 2X
Auto Self-Refresh? No
On-Die Thermal Sensor readout? No
Partial Array Self-Refresh? Yes
Module Thermal Sensor No
SDRAM Device Type Standard Monolithic
---=== Physical Characteristics ===---
Module Height 30 mm
Module Thickness 2 mm front, 2 mm back
Module Width 133.35 mm
Module Reference Card B revision 1
Rank 1 Mapping Mirrored
---=== Manufacturer Data ===---
Module Manufacturer Kingston
Manufacturing Location Code 0x07
Manufacturing Date 2017-W38
Assembly Serial Number 0x332DBC11
Part Number 99U5403-466.A00LF
Can be received via decode-dimms command from i2c-tools-perl package. Also need to load modules:
modprobe eeprom
modprobe i2c-i801
Add this functional please.
Right now all the ram info comes from dmidecode. RAM stuff is a massive pain, the data is just jumbled up, random, sometimes it is right, sometimes wrong (when it comes to the array part, like capacity etc).
Adding specific dependencies in inxi is something I try to avoid unless it's absolutely necessary.
For something like this, I'd have to collect data for a long time to see what the actual variations are (RAM and sensors are the two most messed up, randomized, junk data items that inxi deals with, both are basically nightmares to actually deal with, both took over 1 month with heavy beta tester participation to handle the randomness of the data, many, many, debugger datasets were required to get the stuff to be even close to usually right). In RAM basically advanced data is handled with -x/-xx/-xxx or could also be handled for super admin type advanced data with --admin.
The problem is that brand to brand, stick to stick, it's just random. Then it gets worse if users have to actually add modules and another program to read that output. Then there's the matter of deciding what to show.
Then also the question of what differences are there between dmidecode data and i2c-tools, are there even enough to warrant adding dependencies?
it's hard to explain how bad ram data is internally in linux, it's not the fault of linux, it's the fault of the vendors, who all do it randomly and differently, you can never count on one data type even existing for most advanced features in ram reporting. This is why many, many, many, datasets are required before I would even know where to start, what to show, and why to show that and not something else. Obviously, there's no point in showing the output of one of the i2c tools if you want to see the entire output, then you might as well just run that tool.
Basically for stuff like this, I add the tool commands to the inxi debugger output, or pinxi in this case since it would just be experimental, then I wait, but since the package needs to be installed, and modules added, the odds of even getting a usable range of datasets would be super low.
the bright side is this is made by the kernel guys, so you can largely trust what they are doing.
I'd never heard of this set of tools before, it's very specific, and may prove to be too specific for inxi use, but I'd need to see a wide range of system outputs to see what is even there in terms of options and output.
Since I've done ram stuff before, I can promise you, there is a huge difference between the words 'add this feature please' and actually getting it working and meaningful, if the basic ram feature is any indication, that difference is about 1 month, depends on how clean or dirty or consistent or inconsistent the real data is across real systems. This means that it's a possible huge amount of time for a feature that will mean something only to a relative handful of users, most of whom would probably just use the i2c tools directly in the first place.
I'll take a look at the output of the tools, and also add the commands to the debugger just so I can fire off some datasets for myself to see what the data even looks like across a few computers.
This is a list of the tools Debian i2c-tools installs, obviously you'd have to narrow down massively what you actually would expect to see, what actually matters, what does not matter, etc.
/usr/bin/ddcmon
/usr/bin/decode-dimms
/usr/bin/decode-edid
/usr/bin/decode-vaio
/usr/sbin/i2c-stub-from-dump
/usr/sbin/i2cdetect
/usr/sbin/i2cdump
/usr/sbin/i2cget
/usr/sbin/i2cset
/usr/sbin/i2ctransfer
note that:
modprobe i2c-i801
on my system showed modprobe: FATAL: Module 12c-i801 not found in directory /lib/modules/... which makes it kind of a non-starter, if it's not a standard module, then it doesn't really do any good to have a feature that depends on it. But it may just be something builtin to the kernel, I don't know, I get i2c results so maybe it's just part of the kernels now.
But what's worse is this:
sudo decode-dimms
# decode-dimms version $Revision$
Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $code in chr at /usr/bin/decode-dimms line 2106.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $code in sprintf at /usr/bin/decode-dimms line 2111.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $year in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $year in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $week in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $week in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $year in numeric ge (>=) at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $year in sprintf at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $week in sprintf at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $_[0] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[1] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[2] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[3] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value in sprintf at /usr/bin/decode-dimms line 2174.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $code in chr at /usr/bin/decode-dimms line 2106.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $code in sprintf at /usr/bin/decode-dimms line 2111.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $year in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $year in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $week in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $week in bitwise and (&) at /usr/bin/decode-dimms line 2089.
Use of uninitialized value $year in numeric ge (>=) at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $year in sprintf at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $week in sprintf at /usr/bin/decode-dimms line 2092.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value $_[0] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[1] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[2] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $_[3] in sprintf at /usr/bin/decode-dimms line 2117.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 431.
Use of uninitialized value $b in numeric eq (==) at /usr/bin/decode-dimms line 432.
Use of uninitialized value in sprintf at /usr/bin/decode-dimms line 2174.
Those errors should not exist in well written Perl, in inxi, if I see one of those, it's a bug, but this one has many many of them. And this is just the second command I tried running.
After the errors, which means bad perl basically, or poorly tested perl, the output was pretty interesting.
It looks to me, initially, that the only interesting command is: decode-dimms
But that returns quite similar data to dmidecode, just with more details. Note that per dimm data is fairly reliable, unlike memory array data, which is mostly OEM entered random string values which may or may not correspond to reality.
Sample outputfor decode-dimm.
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0052
Guessing DIMM is in bank 3
---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125 OK (0xECEB)
# of bytes written to SDRAM EEPROM 384
Total number of bytes in EEPROM 512
Fundamental Memory type DDR4 SDRAM
SPD Revision 1.1
Module Type UDIMM
EEPROM CRC of bytes 128-253 OK (0xDF74)
---=== Memory Characteristics ===---
Maximum module speed 2400 MHz (PC4-19200)
Size 16384 MB
Banks x Rows x Columns x Bits 16 x 16 x 10 x 64
SDRAM Device Width 8 bits
Ranks 2
Rank Mix Symmetrical
AA-RCD-RP-RAS (cycles) 17-17-17-39
Supported CAS Latencies 21T, 20T, 19T, 18T, 17T, 16T, 15T, 14T, 13T, 12T, 11T, 10T
---=== Timings at Standard Speeds ===---
AA-RCD-RP-RAS (cycles) as DDR4-2400 17-17-17-39
AA-RCD-RP-RAS (cycles) as DDR4-2133 15-15-15-35
AA-RCD-RP-RAS (cycles) as DDR4-1866 13-13-13-30
AA-RCD-RP-RAS (cycles) as DDR4-1600 11-11-11-26
---=== Timing Parameters ===---
Minimum Cycle Time (tCKmin) 0.833 ns
Maximum Cycle Time (tCKmax) 1.900 ns
Minimum CAS Latency Time (tAA) 13.750 ns
Minimum RAS to CAS Delay (tRCD) 13.750 ns
Minimum Row Precharge Delay (tRP) 13.750 ns
Minimum Active to Precharge Delay (tRAS) 32.000 ns
Minimum Active to Auto-Refresh Delay (tRC) 45.750 ns
Minimum Recovery Delay (tRFC1) 350.000 ns
Minimum Recovery Delay (tRFC2) 260.000 ns
Minimum Recovery Delay (tRFC4) 160.000 ns
Minimum Four Activate Window Delay (tFAW) 21.000 ns
Minimum Row Active to Row Active Delay (tRRD_S) 3.300 ns
Minimum Row Active to Row Active Delay (tRRD_L) 4.900 ns
Minimum CAS to CAS Delay (tCCD_L) 5.000 ns
Minimum Write Recovery Time (tWR) 15.000 ns
Minimum Write to Read Time (tWTR_S) 2.500 ns
Minimum Write to Read Time (tWTR_L) 7.500 ns
---=== Other Information ===---
Package Type Monolithic
Maximum Activate Count Unlimited
Post Package Repair One row per bank group
Soft PPR Supported
Module Nominal Voltage 1.2 V
Thermal Sensor No
---=== Physical Characteristics ===---
Module Height 32 mm
Module Thickness 2 mm front, 2 mm back
Module Reference Card B revision 1
---=== Manufacturer Data ===---
Module Manufacturer Undefined
Part Number Undefined
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0053
Guessing DIMM is in bank 4
---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125 OK (0xECEB)
# of bytes written to SDRAM EEPROM 384
Total number of bytes in EEPROM 512
Fundamental Memory type DDR4 SDRAM
SPD Revision 1.1
Module Type UDIMM
EEPROM CRC of bytes 128-253 OK (0xDF74)
---=== Memory Characteristics ===---
Maximum module speed 2400 MHz (PC4-19200)
Size 16384 MB
Banks x Rows x Columns x Bits 16 x 16 x 10 x 64
SDRAM Device Width 8 bits
Ranks 2
Rank Mix Symmetrical
AA-RCD-RP-RAS (cycles) 17-17-17-39
Supported CAS Latencies 21T, 20T, 19T, 18T, 17T, 16T, 15T, 14T, 13T, 12T, 11T, 10T
---=== Timings at Standard Speeds ===---
AA-RCD-RP-RAS (cycles) as DDR4-2400 17-17-17-39
AA-RCD-RP-RAS (cycles) as DDR4-2133 15-15-15-35
AA-RCD-RP-RAS (cycles) as DDR4-1866 13-13-13-30
AA-RCD-RP-RAS (cycles) as DDR4-1600 11-11-11-26
---=== Timing Parameters ===---
Minimum Cycle Time (tCKmin) 0.833 ns
Maximum Cycle Time (tCKmax) 1.900 ns
Minimum CAS Latency Time (tAA) 13.750 ns
Minimum RAS to CAS Delay (tRCD) 13.750 ns
Minimum Row Precharge Delay (tRP) 13.750 ns
Minimum Active to Precharge Delay (tRAS) 32.000 ns
Minimum Active to Auto-Refresh Delay (tRC) 45.750 ns
Minimum Recovery Delay (tRFC1) 350.000 ns
Minimum Recovery Delay (tRFC2) 260.000 ns
Minimum Recovery Delay (tRFC4) 160.000 ns
Minimum Four Activate Window Delay (tFAW) 21.000 ns
Minimum Row Active to Row Active Delay (tRRD_S) 3.300 ns
Minimum Row Active to Row Active Delay (tRRD_L) 4.900 ns
Minimum CAS to CAS Delay (tCCD_L) 5.000 ns
Minimum Write Recovery Time (tWR) 15.000 ns
Minimum Write to Read Time (tWTR_S) 2.500 ns
Minimum Write to Read Time (tWTR_L) 7.500 ns
---=== Other Information ===---
Package Type Monolithic
Maximum Activate Count Unlimited
Post Package Repair One row per bank group
Soft PPR Supported
Module Nominal Voltage 1.2 V
Thermal Sensor No
---=== Physical Characteristics ===---
Module Height 32 mm
Module Thickness 2 mm front, 2 mm back
Module Reference Card B revision 1
---=== Manufacturer Data ===---
Module Manufacturer Undefined
Part Number Undefined
Number of SDRAM DIMMs detected and decoded: 2
Compare this to dmidecode:
Handle 0x0033, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0027
Error Information Handle: 0x0032
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: Unknown
Set: None
Locator: DIMM 0
Bank Locator: P0 CHANNEL B
Type: Unknown
Type Detail: Unknown
Speed: Unknown
Manufacturer: Unknown
Serial Number: Unknown
Asset Tag: Not Specified
Part Number: Unknown
Rank: Unknown
Configured Memory Speed: Unknown
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
....
Handle 0x0035, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0027
Error Information Handle: 0x0034
Total Width: 64 bits
Data Width: 64 bits
Size: 16384 MB
Form Factor: DIMM
Set: None
Locator: DIMM 1
Bank Locator: P0 CHANNEL B
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 2400 MT/s
Manufacturer: Unknown
Serial Number: <filter>
Asset Tag: Not Specified
Part Number: CT16G4DFD824A.M16FB
Rank: 2
Configured Memory Speed: 2400 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Good output.
So you need more data from users? How much?
Also you can add it as not stable option. So I can package it in Fedora and give you feedback.
No, it's not about the data right now, it's about seeing if there is actually even a point to adding this. In other words, you have to tell me what dmidecode data is missing that decode-dimm has. From the above sample, I see very little that would actually matter in most situations in the decode-dimm, and particularly since the perl is buggy and shoots out errors in the decode-dimm, which wouldn't matter technically since that gets removed, but to me it's a very bad sign that someone puts out code that makes so many errors on my first random test of it.
Keep in mind what is required for this to have any meaning:
- The i2c-tools package has to be installed
- User must be sudo/root to use this
- kernel module eeprom must be available and loaded
The actual thing that's interesting is that because the source of the data is a perl script, inxi can in theory absorb some of the features, since it's about 2000 lines long, but if it were broken down to what data would actually be needed or desired, only those sub routines would be required, so I wouldn't even need to have the i2c-tools package installed if it were only a few lines of data needed from the entire output, which would be the case since there'd be no point in showing it all. The Perl is gpl 2 or later licensed, so it can be used in inxi, though it would be modified.
My feeling is that if there is anything that really is worth showing for advanced --admin ram data, it's only going to be one or two items from the total in decode-dimm.
At least it show RAM timings - current and supported by RAM module. It is only way to see timings in linux.
Timings has same importance as RAM speed.
If it's one single item, timings, then it would just be a matter of pulling that logic out of the decode-dimm thing and putting it into inxi. I'd have to figure out how to test for module load in perl, but maybe the script has that test.
It is first and major item. Other I am not see yet. May be Banks x Rows x Columns x Bits also.
Is fhis the timings you are referring to? that's the only ones that would make real sense to show, the other ns timings are too specific and take too much room to show, unless it's only one or two or three of them that matter.
---=== Timings at Standard Speeds ===---
AA-RCD-RP-RAS (cycles) as DDR4-2400 17-17-17-39
AA-RCD-RP-RAS (cycles) as DDR4-2133 15-15-15-35
AA-RCD-RP-RAS (cycles) as DDR4-1866 13-13-13-30
AA-RCD-RP-RAS (cycles) as DDR4-1600 11-11-11-26
Tentatively I'd say I'm unlikely to do this, though I will add a debugger item to collect the output of decode-dimms just to see what I can get over some time.
I try to avoid features that add too many dependencies to inxi, but when a dependency itself requires a further action of loading the module I don't see how that would help that many users, maybe a tiny handful of sys admins, maybe.
The decode-dimms is just complicated enough, and not well written enough, to be a little harder to pull stuff out than it should be (making linear flow programming mixed with subs is... strange... since it makes it so much less powerful and flexible). Essentially I'd have to almost refactor decode-dimms to use it internally, and to fix all its bugs.
which would mean just having i2c-tools + module eeprom loaded as new dependencies for using this feature, that's not terrible since I wouldn't have to care about how badly written the script is since I'd just be using its output, but unfortunately, weak programming is often manifested in these types of bugs, which would make me mistrust the actual script itself, which would make me want to clone the features I wanted to use long term, which is too much work at this point.
So at this point, I'd need a line by line listing of which output items were of interest, that would help decide it I think, then I'd have to run a few debuggers and see what data is actually there across a variety of systems, to see if there's even a point to trying to add this.
I've thought about this a bit, and my conclusion is that if I'll add ram timings, I'm going to pull the code out of the other program, but only the code required to do it. While it would still require eeprom module loaded, there would be no further dependencies for this essentially single field/value feature. This will be a very low priority item, but I'm going to leave this up as a reminder if one day I get really bored and want to poke at it.