[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