[LinuxBIOS] E7501 SDRAM timing bug?

Steven J. Magnani steve at digidescorp.com
Tue Jun 14 19:32:45 CEST 2005

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.


More information about the coreboot mailing list