Re: EPIA-M SPD progress
Dave Ashley <[EMAIL PROTECTED]> 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
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
* ron minnich <[EMAIL PROTECTED]> [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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
src/sdram/smbus_pcibus.inc has some smbus code, I was able to compile it into the epia-m tree and do some test SMBUS_READ_BYTE calls that actually read out values from the ddr eeprom. I had to #if out the section that actually does the dram configuration to get it to compile. I'm in a bad way for experimenting with this, I have to physically remove the BIOS and plug in a new one if something goes bad, and do the reverse to recover. I've fried 2 motherboards with my pliers rubbing out traces under the flashrom socket (good luck fixing that!). If the dram settings are wrong it might make the product flaky. We're trying to field some units for in situ testing real soon, and the system has to be solid. We can probably hardcode the dram configuration for our known good ddr module that we're using mostly. However I'd like the system to function the right way. I'll keep messing with it for now. -Dave >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 > ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
Stefan Reinauer wrote: * ron minnich <[EMAIL PROTECTED]> [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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
On Fri, 18 Jul 2003 17:07:49 -0500, Bari Ari wrote: >Stefan Reinauer wrote: > >>* ron minnich <[EMAIL PROTECTED]> [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 > > >___ >Linuxbios mailing list >[EMAIL PROTECTED] >http://www.clustermatic.org/mailman/listinfo/linuxbios Hi there, I don;t know wether this is of any assistance in your problem, but i recently wrote an application to read and re-program the Serial EEPROMs, used for SPD, to allow a 128Mb part to work in an old 64Mb application. Would this be of any help to anyone? Its a Labview (see www.ni.com) application and the programming was achieved through the PC parallel port. Cheers for now AS -- Alex Scarbro, [EMAIL PROTECTED] on 18/07/2003 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#]
Hi Dave, > src/sdram/smbus_pcibus.inc has some smbus code, I was able to compile it > into the epia-m tree and do some test SMBUS_READ_BYTE calls that actually > read out values from the ddr eeprom. I had to #if out the section that > actually does the dram configuration to get it to compile. > I'm in a bad way for experimenting with this, I have to physically remove > the BIOS and plug in a new one if something goes bad, and do the reverse > to recover. I've fried 2 motherboards with my pliers rubbing out traces > under the flashrom socket (good luck fixing that!). BIOS Savior will save you. :) -Andrew -- Andrew Ip Email: [EMAIL PROTECTED] Tel:(852) 2542 2046 Fax:(852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: EPIA-M SPD progress [PMX:#] [PMX:#]
On Fri, 18 Jul 2003, Dave Ashley wrote: > the BIOS and plug in a new one if something goes bad, and do the reverse > to recover. I've fried 2 motherboards with my pliers rubbing out traces > under the flashrom socket (good luck fixing that!). you need to go to radioshack and get the flash part extractors. They are perfect for this. Also, failing that, put dental floss under the chip when you install and and then you can lift it out (thanks to Steve James for this one). ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
