[LinuxBIOS] E7501 SDRAM timing bug?

Steven J. Magnani steve at digidescorp.com
Tue Jun 14 19:52:37 CEST 2005


The translation is fine, the issue was present in the V1 code. Probably
it's one of those things where the DRAM would work fine (if slower than
necessary) regardless of the SPD value.

Steve

-----Original Message-----
From: YhLu [mailto:YhLu at tyan.com] 
Sent: Tuesday, June 14, 2005 11:41 AM
To: Steven J. Magnani; 'Ronald G. Minnich'
Cc: linuxbios at openbios.org
Subject: RE: [LinuxBIOS] E7501 SDRAM timing bug?


Good,

Can you compare the raminit.inc in V1, and raminit.c in V2?

So make sure if my translation cause problm.

Thanks

YH 

> -----Original Message-----
> From: Steven J. Magnani [mailto:steve at digidescorp.com]
> Sent: Tuesday, June 14, 2005 10:33 AM
> To: 'Ronald G. Minnich'
> Cc: linuxbios at openbios.org
> Subject: [LinuxBIOS] E7501 SDRAM timing bug?
> 
> Another suspicious looking bit of E7501 RAM initialization code...in
> spd_set_dram_controller_mode() there is code that reads the
> SPD address/command hold time and configures the E7501 for 
> "1n rule" or "2n rule" operation: 
> 
> 		value = spd_read_byte(ctrl->channel0[i], 33);
> /* Address and command hold time after clock */
> 		if(value < 0) continue;
> 		if(value >= 0xa0) { 		/* At 133Mhz this
> constant should be 0x75 */
> 			dword &= ~(1<<16);	/* Use two clock cyles
> instead of one */
> 		}
> 
> The issues here are frequency and scale.
> 
> The rest of the E7501 code assumes 133 MHz operation. So it
> looks from the comments like the comparison to 0xa0 should 
> really be to 0x75. 
> 
> But the SPD value is in _tenths_ of nanoseconds. So the above
> code translates to, "if the address/hold time is more than 1 
> ns, use 2 clock cycles per command". But the clock period is 
> 10 ns for 100 MHz or 7.5 ns for 133 MHz, which is an order of 
> magnitude larger than the SPD values. 
> 
> I didn't see code for any other chipset that did something
> like this, except the Intel 855pm - where it's #ifdef'd out. 
> I'm thinking this code should be removed.
> 
> Steve
> www.digidescorp.com
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org 
> http://www.openbios.org/mailman/listinfo/linuxbios
> 







More information about the coreboot mailing list