[LinuxBIOS] E7501 SDRAM timing bug?

YhLu YhLu at tyan.com
Tue Jun 14 19:40:57 CEST 2005


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