I used the freebios/util/scanspd code as a starting point and found out the DDR ram is at slot 0x50 and can be accessed through standard SMBus reads at io ports 0x500+. A dump of my working eeprom is this: 128 8 7 12 10 1 64 0 4 117 117 0 128 8 0 1 14 4 12 1 2 32 0 160 117 0 0 80 60 80 45 32 144 144 80 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 156 Then 0's. These are read using int i; unsigned char val; smbus_wait_until_ready(); for(i=0;i<64;++i) { smbus_read_byte(0x50,i,&val); printf("%d%c",val, (i&15)==15 ? '\n' : ' '); } The southbridge vt8235 code sets 1106:3177 RxD1 + RxD2 in its misc_setup.inc. So standard smbus reads should be available at dram init time. Probe vs SPD discussion: I think the question is which produces a better result, regardless of complexity. Probing seems to have disadvantages in that it can't know how to set timing amounts, signal levels, or clock delays. It would only allow you to figure out the right column bit size I expect. What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want? -Dave
On Fri, 18 Jul 2003, Dave Ashley wrote:
What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want?
some SPD roms have incorrect information. You have to take care with SPD. Overall, SPD is better. However, if you are on a short fuse and need to deliver soon, I would go with probing for now and restrict the type of ram you use. Longer term, we want to do SPD. ron
* ron minnich <rminnich@lanl.gov> [030718 21:12]:
On Fri, 18 Jul 2003, Dave Ashley wrote:
What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want?
some SPD roms have incorrect information. You have to take care with SPD.
Does this happen if you buy cheap ram, or ram of a certain type? How can this kind of problem be avoided? I heard and read this a couple of times now, but (I think) it never happened to me 'til now Stefan -- Architecture Team SuSE Linux AG
On Fri, 18 Jul 2003, Stefan Reinauer wrote:
some SPD roms have incorrect information. You have to take care with SPD.
Does this happen if you buy cheap ram, or ram of a certain type?
You need to find quality vendors and stick with them. Even then, you can get in trouble.
How can this kind of problem be avoided? I heard and read this a couple of times now, but (I think) it never happened to me 'til now
It can't as long as vendors mix up SEEPROM and DRAM parts incorrectly. ron
Stefan Reinauer wrote:
* ron minnich <rminnich@lanl.gov> [030718 21:12]:
On Fri, 18 Jul 2003, Dave Ashley wrote:
What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want?
some SPD roms have incorrect information. You have to take care with SPD.
Does this happen if you buy cheap ram, or ram of a certain type? How can this kind of problem be avoided? I heard and read this a couple of times now, but (I think) it never happened to me 'til now
SPD only works if the RAM vendor properly programs the serial EEPROM. RAM is a commodity item and vendors churn out millions of modules a year. An assembly line can build thousands of modules per day. If there is a hickup on the procurement side (parts not showing up or late for assembly) an assembler may be forced to use a different part number that is in stock that is still compatible with the module pcb layout but does not have the same timing specs. Other times the SPD info is just programmed wrong and the only QC is based on the end user complaining about a problem. Another way that SPD breaks is by flaky software or SPD bus corruption that writes data to the SPD device on the RAM module. Don't be surprised by how much broken PC hardware gets sent off to market with fixes via BIOS and other still broken means. -Bari
Dave Ashley <linuxbios@xdr.com> writes:
I used the freebios/util/scanspd code as a starting point and found out the DDR ram is at slot 0x50 and can be accessed through standard SMBus reads at io ports 0x500+. A dump of my working eeprom is this:
128 8 7 12 10 1 64 0 4 117 117 0 128 8 0 1 14 4 12 1 2 32 0 160 117 0 0 80 60 80 45 32 144 144 80 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 156 Then 0's.
These are read using int i; unsigned char val; smbus_wait_until_ready(); for(i=0;i<64;++i) { smbus_read_byte(0x50,i,&val); printf("%d%c",val, (i&15)==15 ? '\n' : ' '); }
The southbridge vt8235 code sets 1106:3177 RxD1 + RxD2 in its misc_setup.inc. So standard smbus reads should be available at dram init time.
Probe vs SPD discussion: I think the question is which produces a better result, regardless of complexity. Probing seems to have disadvantages in that it can't know how to set timing amounts, signal levels, or clock delays. It would only allow you to figure out the right column bit size I expect. What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want?
SPD is required for DDR SDRAM because there are no universally safe timings, that will work with all DIMMS. Universally safe timings existed with SDRAM. As for SPD information being buggy. Yes vendors can put the wrong labels on their products. If someone cares you can usually write the SPD just as easily as you can read from it, so you can fix the bad SPD data. Since SPD usage is mandatory for DDR SDRAM it is usually supported. Eric
On Fri, Jul 18, 2003 at 11:42:12AM -0700, Dave Ashley wrote:
Probe vs SPD discussion: I think the question is which produces a better result, regardless of complexity. Probing seems to have disadvantages in that it can't know how to set timing amounts, signal levels, or clock delays.
I know SPD is the right thing to do, and the complexity is the cost we have to pay for that. Current code for EPIA is just simple and stupid but works for (almost) everyone. Eric said romcc bloats the resulting code since it has to inline all the function calls. I understand how hard doing non-inline functions without RAM is but code bloat sounds not very sexy to me. I will look into it when I am ready and feel good enough to learn how to read that yet another kind of hex dumps...
It would only allow you to figure out the right column bit size I expect.
And the amount of RAM too of course. :)
What disadvantages does SPD have other than it is more complex? Wouldn't it let you then be able to correctly use any DDR module you want?
I don't know about DDR, but for EPIA, which uses non-DDR SDRAM, so far I haven't heard of a case where the current code fails. On wrong SPD: I figured out why most BIOSes have the setup option to force DRAM parameters other than "By SPD". Do we need that feature too? :) -- Takeshi
On Sun, 20 Jul 2003, SONE Takeshi wrote:
On wrong SPD: I figured out why most BIOSes have the setup option to force DRAM parameters other than "By SPD". Do we need that feature too? :)
We actually have had serious conversations on this. The conclusion was "don't buy busted memory". If there are no universal save DDR settings it will probably be impossible for the BIOS to run long enough to put up a "force DRAM parameters" page anyway. ron
participants (7)
-
Alex Scarbro -
Bari Ari -
Dave Ashley -
ebiederman＠lnxi.com -
ron minnich -
SONE Takeshi -
Stefan Reinauer