|<><><><><> Original message from Eric W. Biederman <><><><><>
|"Thomas J. Merritt" <[EMAIL PROTECTED]> writes:
|
|> |<><><><><> Original message from Eric W. Biederman <><><><><>
|> |Ronald G Minnich <[EMAIL PROTECTED]> writes:
|> |
|> |> On 28 Aug 2001, Eric W. Biederman wrote:
|> |> > I'd be suprised if they don't get it. At least the basics. For
|> |> > things like the AMD760 the documentation spells out fairly clearly
|> |> > where everything should be coming from. And the SPD isn't magic just
|> |> > a label in silcon form that the manufacturers add to their DIMMS.
|> |> >
|> |>
|> |> What we did see on one bios is that they didn't do as good a job with SPD
|> |> as Ollie. I have also been told that BIOS programmers do a suboptimal job
|> |> since there are so many SDRAMs out there with SPD data that is wrong.
|> |
|> |Using SDRAMS with incorrect serial EEPROMS is a lame excuse, for not
|> |using the SPD data.
|>
|> Ok, so what do you recommend the BIOS do in the case that the SPD data
|> is wrong for the SDRAM chips and configuration of the DIMM?
|
|First that DIMM is a manufacturing error so supporting it is being nice.
|For supporting having a seperate mode that reads hard coded parameters
|someone set would be fine. Even detecting such a bad dimm is a challenge.
I agree that a DIMM with bad SPD data is busted hardware and supporting it
is being nice. But early on when SPD's were added to DIMMS most of the
DIMMS that came through had the SPD programmed with all FF's. Recent
DIMMS seems better, but I have seen differences in interpretations of the
definitions. Given that SPD data could not be relied upon early on, I think
it is understandable that BIOS vendors would not overly rely upon it.
Given that some DIMM vendors are consistiently getting get the SPD data
right, I would recommend pushing the memory controller to the limits
and let the ones with bad SPD data just fail.
|> |I think what happens is that board manufactures license a BIOS kit
|> |from award, or ali. Customize it for their board. And then ship the
|> |board. But I don't think this gets much code reuse, between different
|> |board manufacturers. And because you have so many people doing it you
|> |have serious variations in quality.
|>
|> I haven't looked at any of the x86 chipsets very carefully, but to
|> properly use SPD data on other boards I'm familiar with, requires knowing
|> information about board layout and signal propogation. How are your
|> factoring these parameters in to your x86 chipset support?
|
|For all of the parameters I am aware of that are board specific I have
|a lookup table that you can define per motherboard. And if you have a
|really nasty requirement you can even have a subroutinte that you can
|have per motherboard, but I haven't seen anything that would require
|that yet.
This seems pretty reasonable, are you able to ID boards reliably?
|From what I have seen x86 chipsets haven't required a lot of knowledge
|about board layout and signal propogation for setting up SDRAM. You
|can suprise me. I'm not a god in this area just comptetent which was
|my point early. In truth I have seen more problems with registers
|left unitialized that take on random values then I have with timing
|information per motherboard.
Uninitialized registers are definitely a problem. Particularly the
undocumented ones, hopefully x86 vendors are better about this.
TJ Merritt
[EMAIL PROTECTED]
1-415-834-9111
