Memory type info

NTDEV
1

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!

2

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

3

The Bios is accessible at physical address F0000. Have you tried MmMapIoSpace() on that address range ?

Alberto.

----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@ieee.org To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Also, just Google for “Bios Memory Latency”, you get more info than you shopped for!

Alberto.

----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

You can go for example to http://www.corsairmemory.com. They have two PDFs, one’s called “Setting BIOS for Optimal Memory Performance” and the other is “Latency Settings Explained”, they explain all about it, well, almost all. The four-digit setting (like 2-2-5-2, specifying CAS Latency, RAS to CAS delay, Precharge Time and Command Rate) is supposed to be available somewhere inside the Bios, although I cannot find any definite reference that tells me exactly where, except that it’s stored inside an EEPROM that’s accessible through the Bios.

Overclockers fiddle with those settings to extract more performance out of their motherboards, for example, for games. There’s plenty of overclocking web sites that teach you what the settings mean, and apparently some modern bioses allow you to change those settings at boot time, but neither of my machines allow me to change that setting. The OP obviously must know how to access it in his own Bios(es), but that may be one of those things that change from machine to machine and is only privy to the Bios itself.

I looked it up and I couldn’t find an uniform way of extricating the four-digit string out of a Bios in a standard way out of the little EEPROM. Pat, do you know how to do it, and if you do, can you share the info ? Or is this the actual question you’re asking ? If that’s so, you might have better luck in a mailing list specifically dedicated to Bios issues!

Alberto.
----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Definitely OP is looking for (get, and possibly set ) those from BIOS.

  1. So what can be accessed from BIOS in a consistent manner ? Using possibly BIOS lvl interrupt, old fashioned.

  2. How that can be emulated to software ( using VDD to open up interrupt/ port i/o ? ) or write a driver that does the job ?

  3. If it is adriver, should it use BIOS lvl interrupt or if any is available from Hal*() ?

Not sure what would it give to OP just having access to the device …\PhysicalMemory. Probably just the content if I could recall from Nebbett.

-pro
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 7:34 AM
Subject: Re: [ntdev] Memory type info

You can go for example to http://www.corsairmemory.com. They have two PDFs, one’s called “Setting BIOS for Optimal Memory Performance” and the other is “Latency Settings Explained”, they explain all about it, well, almost all. The four-digit setting (like 2-2-5-2, specifying CAS Latency, RAS to CAS delay, Precharge Time and Command Rate) is supposed to be available somewhere inside the Bios, although I cannot find any definite reference that tells me exactly where, except that it’s stored inside an EEPROM that’s accessible through the Bios.

Overclockers fiddle with those settings to extract more performance out of their motherboards, for example, for games. There’s plenty of overclocking web sites that teach you what the settings mean, and apparently some modern bioses allow you to change those settings at boot time, but neither of my machines allow me to change that setting. The OP obviously must know how to access it in his own Bios(es), but that may be one of those things that change from machine to machine and is only privy to the Bios itself.

I looked it up and I couldn’t find an uniform way of extricating the four-digit string out of a Bios in a standard way out of the little EEPROM. Pat, do you know how to do it, and if you do, can you share the info ? Or is this the actual question you’re asking ? If that’s so, you might have better luck in a mailing list specifically dedicated to Bios issues!

Alberto.
----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I was looking around, and I didn’t dig too deep, but it looks like those settings are exercised into the chipset. If the chipset has readable registers, he can fish them out, but then, he’ll have to be able to distinguish chip set A from chip set B and this can be a bit of a can of worms. Someone in a Bios Support web page says that “you may have to dig around a bit” to find this kind of information, and although I don’t know for sure, it looks like this information isn’t always in the same place from Bios to Bios. Also, he might find it inside the CMOS, if he’s lucky, but it doesn’t look like there’s a standard mechanism to get to that data. Yet it’s been over 10 years since I last did Bios work, so, I may be wrong!

Alberto.
.
----- Original Message -----
From: Prokash Sinha
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 10:48 AM
Subject: Re: [ntdev] Memory type info

Definitely OP is looking for (get, and possibly set ) those from BIOS.

  1. So what can be accessed from BIOS in a consistent manner ? Using possibly BIOS lvl interrupt, old fashioned.

  2. How that can be emulated to software ( using VDD to open up interrupt/ port i/o ? ) or write a driver that does the job ?

  3. If it is adriver, should it use BIOS lvl interrupt or if any is available from Hal*() ?

Not sure what would it give to OP just having access to the device …\PhysicalMemory. Probably just the content if I could recall from Nebbett.

-pro
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 7:34 AM
Subject: Re: [ntdev] Memory type info

You can go for example to http://www.corsairmemory.com. They have two PDFs, one’s called “Setting BIOS for Optimal Memory Performance” and the other is “Latency Settings Explained”, they explain all about it, well, almost all. The four-digit setting (like 2-2-5-2, specifying CAS Latency, RAS to CAS delay, Precharge Time and Command Rate) is supposed to be available somewhere inside the Bios, although I cannot find any definite reference that tells me exactly where, except that it’s stored inside an EEPROM that’s accessible through the Bios.

Overclockers fiddle with those settings to extract more performance out of their motherboards, for example, for games. There’s plenty of overclocking web sites that teach you what the settings mean, and apparently some modern bioses allow you to change those settings at boot time, but neither of my machines allow me to change that setting. The OP obviously must know how to access it in his own Bios(es), but that may be one of those things that change from machine to machine and is only privy to the Bios itself.

I looked it up and I couldn’t find an uniform way of extricating the four-digit string out of a Bios in a standard way out of the little EEPROM. Pat, do you know how to do it, and if you do, can you share the info ? Or is this the actual question you’re asking ? If that’s so, you might have better luck in a mailing list specifically dedicated to Bios issues!

Alberto.
----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

I think you gave more than enough info for OP to sweat on for now :slight_smile:

-pro
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 7:58 AM
Subject: Re: [ntdev] Memory type info

I was looking around, and I didn’t dig too deep, but it looks like those settings are exercised into the chipset. If the chipset has readable registers, he can fish them out, but then, he’ll have to be able to distinguish chip set A from chip set B and this can be a bit of a can of worms. Someone in a Bios Support web page says that “you may have to dig around a bit” to find this kind of information, and although I don’t know for sure, it looks like this information isn’t always in the same place from Bios to Bios. Also, he might find it inside the CMOS, if he’s lucky, but it doesn’t look like there’s a standard mechanism to get to that data. Yet it’s been over 10 years since I last did Bios work, so, I may be wrong!

Alberto.
.
----- Original Message -----
From: Prokash Sinha
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 10:48 AM
Subject: Re: [ntdev] Memory type info

Definitely OP is looking for (get, and possibly set ) those from BIOS.

  1. So what can be accessed from BIOS in a consistent manner ? Using possibly BIOS lvl interrupt, old fashioned.

  2. How that can be emulated to software ( using VDD to open up interrupt/ port i/o ? ) or write a driver that does the job ?

  3. If it is adriver, should it use BIOS lvl interrupt or if any is available from Hal*() ?

Not sure what would it give to OP just having access to the device …\PhysicalMemory. Probably just the content if I could recall from Nebbett.

-pro
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 7:34 AM
Subject: Re: [ntdev] Memory type info

You can go for example to http://www.corsairmemory.com. They have two PDFs, one’s called “Setting BIOS for Optimal Memory Performance” and the other is “Latency Settings Explained”, they explain all about it, well, almost all. The four-digit setting (like 2-2-5-2, specifying CAS Latency, RAS to CAS delay, Precharge Time and Command Rate) is supposed to be available somewhere inside the Bios, although I cannot find any definite reference that tells me exactly where, except that it’s stored inside an EEPROM that’s accessible through the Bios.

Overclockers fiddle with those settings to extract more performance out of their motherboards, for example, for games. There’s plenty of overclocking web sites that teach you what the settings mean, and apparently some modern bioses allow you to change those settings at boot time, but neither of my machines allow me to change that setting. The OP obviously must know how to access it in his own Bios(es), but that may be one of those things that change from machine to machine and is only privy to the Bios itself.

I looked it up and I couldn’t find an uniform way of extricating the four-digit string out of a Bios in a standard way out of the little EEPROM. Pat, do you know how to do it, and if you do, can you share the info ? Or is this the actual question you’re asking ? If that’s so, you might have better luck in a mailing list specifically dedicated to Bios issues!

Alberto.
----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Most Asus mobos allow to set these settings manually, instead of relying on Serial Presense Detect logic in the DIMM.
Never used this though.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Alberto Moreira
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 6:34 PM
Subject: Re: [ntdev] Memory type info

You can go for example to http://www.corsairmemory.com. They have two PDFs, one’s called “Setting BIOS for Optimal Memory Performance” and the other is “Latency Settings Explained”, they explain all about it, well, almost all. The four-digit setting (like 2-2-5-2, specifying CAS Latency, RAS to CAS delay, Precharge Time and Command Rate) is supposed to be available somewhere inside the Bios, although I cannot find any definite reference that tells me exactly where, except that it’s stored inside an EEPROM that’s accessible through the Bios.

Overclockers fiddle with those settings to extract more performance out of their motherboards, for example, for games. There’s plenty of overclocking web sites that teach you what the settings mean, and apparently some modern bioses allow you to change those settings at boot time, but neither of my machines allow me to change that setting. The OP obviously must know how to access it in his own Bios(es), but that may be one of those things that change from machine to machine and is only privy to the Bios itself.

I looked it up and I couldn’t find an uniform way of extricating the four-digit string out of a Bios in a standard way out of the little EEPROM. Pat, do you know how to do it, and if you do, can you share the info ? Or is this the actual question you’re asking ? If that’s so, you might have better luck in a mailing list specifically dedicated to Bios issues!

Alberto.
----- Original Message -----
From: Loren Wilton
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 3:54 AM
Subject: Re: [ntdev] Memory type info

Last I looked rams didn’t give a readout of manufacturer and suchlike data; or indeed any readout at all (except in some cases for size). They just store bits. You can maybe find out how the bios is configured to deal with the ram in terms of latency and size and whatnot. But beyond that, you have to pull the chip/dimm/whatever, read the numbers on the side, and look them up in a data book.

Loren
----- Original Message -----
From: zed hex
To: Windows System Software Devs Interest List
Sent: Saturday, April 09, 2005 12:21 AM
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool. We currently use WMI from user-mode but its not particularly effective - basically it doesn’t get any details of RAM type about 50 percent of the time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware directly. Does anyone have any information of how this is to be achieved? I have found out how to map the \device\physicalMemory object to user mode and then access the BIOS data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but there seems to be nothing available. Any pointers at all would be highly appreciated.

Pat Magee

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@earthlink.net To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

You can take a look at memory information in SMBIOS tables
http://www.dmtf.org/standards/smbios/
V2.3.4, chapter 3.3.18 Memory Device (Type 17).
Unfortunately many BIOSes don’t bother to correctly
populate this table.

Another ways to get memory info are:

  1. read SPD ROMs using motherboard/chipset SMBUS controller
  2. read chipset memory controller PCI config space registers.

These methods are chipset and motherboard specific so
probably they are not practical for you.

Dmitriy Budko, VMware

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of zed hex
Sent: Saturday, April 09, 2005 12:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool.
We currently use WMI from user-mode but its not particularly effective -
basically it doesn’t get any details of RAM type about 50 percent of the
time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware
directly. Does anyone have any information of how this is to be achieved? I
have found out how to map the \device\physicalMemory object to user mode and
then access the BIOS data - but that still doesn’t get me the latency data I
need.

I have been digging around for months trying to find some info, but there
seems to be nothing available. Any pointers at all would be highly
appreciated.

Pat Magee

11

Is there any vendor name in SPD? or only size+timing characteristics?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Dmitriy Budko”
To: “Windows System Software Devs Interest List”
Sent: Monday, April 11, 2005 4:14 AM
Subject: RE: [ntdev] Memory type info

You can take a look at memory information in SMBIOS tables
http://www.dmtf.org/standards/smbios/
V2.3.4, chapter 3.3.18 Memory Device (Type 17).
Unfortunately many BIOSes don’t bother to correctly
populate this table.

Another ways to get memory info are:
1) read SPD ROMs using motherboard/chipset SMBUS controller
2) read chipset memory controller PCI config space registers.

These methods are chipset and motherboard specific so
probably they are not practical for you.

Dmitriy Budko, VMware

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of zed hex
Sent: Saturday, April 09, 2005 12:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Memory type info

I need to access the memory configuration data for a system diagnostics tool.
We currently use WMI from user-mode but its not particularly effective -
basically it doesn’t get any details of RAM type about 50 percent of the
time, and no latency/manufacturer info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the hardware
directly. Does anyone have any information of how this is to be achieved? I
have found out how to map the \device\physicalMemory object to user mode and
then access the BIOS data - but that still doesn’t get me the latency data I
need.

I have been digging around for months trying to find some info, but there
seems to be nothing available. Any pointers at all would be highly
appreciated.

Pat Magee

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

12

There is a Vendor JEDEC ID code but it is optional :frowning:

Dmitriy Budko, VMware
xxxxx@vmware.com

Is there any vendor name in SPD? or only size+timing
characteristics?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Dmitriy Budko”
To: “Windows System Software Devs Interest List”
> Sent: Monday, April 11, 2005 4:14 AM
> Subject: RE: [ntdev] Memory type info
>
>
> You can take a look at memory information in SMBIOS tables
> http://www.dmtf.org/standards/smbios/
> V2.3.4, chapter 3.3.18 Memory Device (Type 17).
> Unfortunately many BIOSes don’t bother to correctly
> populate this table.
>
> Another ways to get memory info are:
> 1) read SPD ROMs using motherboard/chipset SMBUS controller
> 2) read chipset memory controller PCI config space registers.
>
> These methods are chipset and motherboard specific so
> probably they are not practical for you.
>
>
> Dmitriy Budko, VMware

13

Pat,

Just to clear up what everyone else has said, and add my sentiments:

  1. You can get the info from the RAM itself, via the SMBus. Unfortunately,
    SMBus is relatively motherboard/chipset specific, so you may need to write
    specific drivers for each type of motherboard/chipset, and of course update
    frequently when new motherboards/chipsets come out.
  2. Even if you read out that the MEMORY is (say) 5-2-2-2 timing @ 400MHz,
    it doesn’t necessarily mean that the chipset is set for this timing. To
    read the chipset, you will need to read PCI configuration space for the
    chipset, and of course, this is vendor and model specific, so you’ll need
    to support each individual chipset in it’s own way. Not only that, but the
    documentation for the chipset may not be available to the general public,
    and it’s not always that easy to get the NDA documentation you need for
    these purposes, unless you’re in a big, well-known company [I once worked with one of the people that does one of the more well-known system analysis tools, and the guy I worked with was moaning badly at the Taiwanese companies for not giving him the information he needed until 6 months or so after the chipset was out on the market, which makes life a misery].

So, in summary, yes you can get this information with a driver, BUT it’s
not going to be easy, and it’s maintenance nightmare…

Of course, you could potentially “find out” what the memory parameters are
by just doing some experiments on uncached memory accesses. But I’m not
sure if that’s going to work reliably, I haven’t tried…

–
Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 04/09/2005 08:21:59 AM:

I need to access the memory configuration data for a system
diagnostics tool. We currently use WMI from user-mode but its not
particularly effective - basically it doesn’t get any details of
RAM type about 50 percent of the time, and no latency/manufacturer
info at all :frowning:

So I now have to write a kernel mode psuedo-driver to access the
hardware directly. Does anyone have any information of how this is
to be achieved? I have found out how to map the
\device\physicalMemory object to user mode and then access the BIOS
data - but that still doesn’t get me the latency data I need.

I have been digging around for months trying to find some info, but
there seems to be nothing available. Any pointers at all would be
highly appreciated.

Pat Magee

14

Thanks for everyones contributions, but its kinda what
I feared - a great big headache! Reading the SMBIOS
isn’t too hard, just map 0xF000 into user-mode using
NtViewSection, and then scan it for ‘SM’, ‘$PNP’ and
a few other known strings. But unfortunately the
SMBios doesn’t have everything I need - and you can
get almost all that stuff from the Win32_Bios class
via WMI.

So really I need the NDA info or I’m sunk? I thought
that might be the case. I’m pretty much a one man show
software developer - so the chances of getting
anything out of the more tight-lipped chipset
manufacturers is just about zero. Some (notably VIA)
dont release a damned thing. Strangely enough Intel
still print their datasheets with everything I’d need
including the memory standards documentation for the
layout of the EEPROM config tables, except that they
give very little on accessing their
memory-controllers.

BIOS manufacturers are equally unhelpful - I have
tried asking Phoenix and AMI and they basically only
have info for BIOS writers. Once the system is up and
running they aren’t much help.

So how do I talk to the SMBus controller? Are there
any samples I can start from? The SmbBatt sample in
the DDK is rather unhelpful as it is primarily aimed
at writing an SMBus device. The DDK documentation is
very lean indeed on diagnostics in general (then
again, I guess it isn’t called the Device Driver Kit
for nothing - and I’m not really writing a driver at
all).

So does anyone know I’d go about reading the PCI
config space of a chipset memory controller? All the
samples in the DDK assume that I’d be calling it from
within its own driver stack, but of course I won’t be.
From some reading it seems that I’ll need to write a
filter driver and attach it to the memory controllers
device stack. Is that true? Are there are any filter
driver examples out there that do this?

Thanks again for any comments

Pat

— Mats PETERSSON wrote:
>
>
>
>
>
> Pat,
>
> Just to clear up what everyone else has said, and
> add my sentiments:
> 1. You can get the info from the RAM itself, via the
> SMBus. Unfortunately,
> SMBus is relatively motherboard/chipset specific, so
> you may need to write
> specific drivers for each type of
> motherboard/chipset, and of course update
> frequently when new motherboards/chipsets come out.
> 2. Even if you read out that the MEMORY is (say)
> 5-2-2-2 timing @ 400MHz,
> it doesn’t necessarily mean that the chipset is set
> for this timing. To
> read the chipset, you will need to read PCI
> configuration space for the
> chipset, and of course, this is vendor and model
> specific, so you’ll need
> to support each individual chipset in it’s own way.
> Not only that, but the
> documentation for the chipset may not be available
> to the general public,
> and it’s not always that easy to get the NDA
> documentation you need for
> these purposes, unless you’re in a big, well-known
> company [I once worked<br>&gt; with one of the people that does one of the more<br>&gt; well-known system analysis<br>&gt; tools, and the guy I worked with was moaning badly<br>&gt; at the Taiwanese<br>&gt; companies for not giving him the information he<br>&gt; needed until 6 months or so<br>&gt; after the chipset was out on the market, which makes<br>&gt; life a misery].
>
> So, in summary, yes you can get this information
> with a driver, BUT it’s
> not going to be easy, and it’s maintenance
> nightmare…
>
> Of course, you could potentially “find out” what the
> memory parameters are
> by just doing some experiments on uncached memory
> accesses. But I’m not
> sure if that’s going to work reliably, I haven’t
> tried…
>
> –
> Mats
>
> -------- Notice --------
> The information in this message is confidential and
> may be legally
> privileged. It is intended solely for the
> addressee. Access to this
> message by anyone else is unauthorized. If you are
> not the intended
> recipient, any disclosure, copying or distribution
> of the message, or any
> action taken by you in reliance on it, is prohibited
> and may be unlawful.
> If you have received this message in error, please
> delete it and contact
> the sender immediately. Thank you.
>
>
> xxxxx@lists.osr.com wrote on
> 04/09/2005 08:21:59 AM:
>
> > I need to access the memory configuration data for
> a system
> > diagnostics tool. We currently use WMI from
> user-mode but its not
> > particularly effective - basically it doesn’t get
> any details of
> > RAM type about 50 percent of the time, and no
> latency/manufacturer
> > info at all :frowning:
> >
> > So I now have to write a kernel mode psuedo-driver
> to access the
> > hardware directly. Does anyone have any
> information of how this is
> > to be achieved? I have found out how to map the
> > \device\physicalMemory object to user mode and
> then access the BIOS
> > data - but that still doesn’t get me the latency
> data I need.
> >
> > I have been digging around for months trying to
> find some info, but
> > there seems to be nothing available. Any pointers
> at all would be
> > highly appreciated.
> >
> > Pat Magee
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

15

I’ll try to answer as much of the questions as I can…

xxxxx@lists.osr.com wrote on 04/12/2005 06:34:30 PM:

Thanks for everyones contributions, but its kinda what
I feared - a great big headache! Reading the SMBIOS
isn’t too hard, just map 0xF000 into user-mode using
NtViewSection, and then scan it for ‘SM’, ‘$PNP’ and
a few other known strings. But unfortunately the
SMBios doesn’t have everything I need - and you can
get almost all that stuff from the Win32_Bios class
via WMI.

Fairly typical. If it’s easy to get to, you can easily get it some other
way, but if it’s hard to get to in the first place, there’s no other “easy”
way either… :wink:

So really I need the NDA info or I’m sunk? I thought
that might be the case. I’m pretty much a one man show
software developer - so the chances of getting
anything out of the more tight-lipped chipset
manufacturers is just about zero. Some (notably VIA)
dont release a damned thing. Strangely enough Intel
still print their datasheets with everything I’d need
including the memory standards documentation for the
layout of the EEPROM config tables, except that they
give very little on accessing their
memory-controllers.

NDA would help, and VIA is one of the companies that do not support
software developers very well (or at all?).

I just checked the Intel 875 chipset manual, and it certainly has the
memory timing (cas-latency, etc) in the manual. Same with the AMD manual
(BIOS & Kernel programmers manual or whatever it’s called). I wasn’t able
to find the memory clock rate in the Intel document, but I only spent a few
minutes looking at it, so perhaps it’s there if you look more carefully.
However, it may be that the memory clock is controlled by an external clock
generator, which in that case is controlled by SMBus, most likely. [This
makes it harder, as there are half a dozen different clock generators on
the market, each with it’s own version of programming protocol, and they
may even have variable inputs (i.e. you could drive it with a 100MHz, 50MHz
or 33MHz clock, and then program it to 1x, 2x or 3x to generate a 100MHz
output clock, for instance]

BIOS manufacturers are equally unhelpful - I have
tried asking Phoenix and AMI and they basically only
have info for BIOS writers. Once the system is up and
running they aren’t much help.

They don’t want you to be able to do BIOS work without paying their license
fee, is my guess… :frowning:

So how do I talk to the SMBus controller? Are there
any samples I can start from? The SmbBatt sample in
the DDK is rather unhelpful as it is primarily aimed
at writing an SMBus device. The DDK documentation is
very lean indeed on diagnostics in general (then
again, I guess it isn’t called the Device Driver Kit
for nothing - and I’m not really writing a driver at
all).

There is a set of registers somewhere in the “Southbridge” which you can
use to communicate to the SMBus. It’s an implementation of I2C, and you
should have something like an address register, and a data register, and a
control register. Write an address (that of the SPD, which I haven’t got a
clue what value it would be, but that’s probably your smallest problem),
write a “read” command to the control register, and wait for the read to
come through.

There is a Linux driver for SMBus that is pretty useful for showing how
this is done. I’m not sure where you find it, but a google for “Linux SMBus
Driver” should get you to it.

One problem however, is that the BIOS may well do things on the SMBus (like
checking fan speed or CPU temperature), even when running Windows, using
SMI to run the BIOS code. This would essentially prevent you from doing
this, but it may not be a problem in most cases (there seem to be several
packages that measure fan-speed and cpu-temp on the market, so it should be
possible to achieve something).

So does anyone know I’d go about reading the PCI
config space of a chipset memory controller? All the
samples in the DDK assume that I’d be calling it from
within its own driver stack, but of course I won’t be.
From some reading it seems that I’ll need to write a
filter driver and attach it to the memory controllers
device stack. Is that true? Are there are any filter
driver examples out there that do this?

You should be able to do that from a kernel driver, using the PCIReadConfig
function. I think that combined with PCIWriteConfig could be used to
communicate with the SMBus too.

–
Mats

Thanks again for any comments

Pat

— Mats PETERSSON wrote:
> >
> >
> >
> >
> >
> > Pat,
> >
> > Just to clear up what everyone else has said, and
> > add my sentiments:
> > 1. You can get the info from the RAM itself, via the
> > SMBus. Unfortunately,
> > SMBus is relatively motherboard/chipset specific, so
> > you may need to write
> > specific drivers for each type of
> > motherboard/chipset, and of course update
> > frequently when new motherboards/chipsets come out.
> > 2. Even if you read out that the MEMORY is (say)
> > 5-2-2-2 timing @ 400MHz,
> > it doesn’t necessarily mean that the chipset is set
> > for this timing. To
> > read the chipset, you will need to read PCI
> > configuration space for the
> > chipset, and of course, this is vendor and model
> > specific, so you’ll need
> > to support each individual chipset in it’s own way.
> > Not only that, but the
> > documentation for the chipset may not be available
> > to the general public,
> > and it’s not always that easy to get the NDA
> > documentation you need for
> > these purposes, unless you’re in a big, well-known
> > company [I once worked<br>&gt; &gt; with one of the people that does one of the more<br>&gt; &gt; well-known system analysis<br>&gt; &gt; tools, and the guy I worked with was moaning badly<br>&gt; &gt; at the Taiwanese<br>&gt; &gt; companies for not giving him the information he<br>&gt; &gt; needed until 6 months or so<br>&gt; &gt; after the chipset was out on the market, which makes<br>&gt; &gt; life a misery].
> >
> > So, in summary, yes you can get this information
> > with a driver, BUT it’s
> > not going to be easy, and it’s maintenance
> > nightmare…
> >
> > Of course, you could potentially “find out” what the
> > memory parameters are
> > by just doing some experiments on uncached memory
> > accesses. But I’m not
> > sure if that’s going to work reliably, I haven’t
> > tried…
> >
> > –
> > Mats
> >
> > -------- Notice --------
> > The information in this message is confidential and
> > may be legally
> > privileged. It is intended solely for the
> > addressee. Access to this
> > message by anyone else is unauthorized. If you are
> > not the intended
> > recipient, any disclosure, copying or distribution
> > of the message, or any
> > action taken by you in reliance on it, is prohibited
> > and may be unlawful.
> > If you have received this message in error, please
> > delete it and contact
> > the sender immediately. Thank you.
> >
> >
> > xxxxx@lists.osr.com wrote on
> > 04/09/2005 08:21:59 AM:
> >
> > > I need to access the memory configuration data for
> > a system
> > > diagnostics tool. We currently use WMI from
> > user-mode but its not
> > > particularly effective - basically it doesn’t get
> > any details of
> > > RAM type about 50 percent of the time, and no
> > latency/manufacturer
> > > info at all :frowning:
> > >
> > > So I now have to write a kernel mode psuedo-driver
> > to access the
> > > hardware directly. Does anyone have any
> > information of how this is
> > > to be achieved? I have found out how to map the
> > > \device\physicalMemory object to user mode and
> > then access the BIOS
> > > data - but that still doesn’t get me the latency
> > data I need.
> > >
> > > I have been digging around for months trying to
> > find some info, but
> > > there seems to be nothing available. Any pointers
> > at all would be
> > > highly appreciated.
> > >
> > > Pat Magee
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@yahoo.com
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT00010922