[coreboot] v2: Detection of sdram densities.

[Mats Erik Andersson]

Hello all,

to round off this thread, I must agree with you on the confusing
terminology for SDRAM modules/devices/cards. Until Monday
this week I thought that an SDRAM-card consisted of one or
two memory banks, depending on the number of physically
populated sides of the memory carrier. Then I began
studying Intel's publication

    PC SDRAM Serial Presence Detect (SPD) Specification

and all the expected terms were turned around, and it was
with that phrasing my original question was posed. Both of
you, Joseph and Corey, quickly caught this, and thus resolved
my dilemma. 

I am porting Uwe Hammer's code for msi/ms6119 to the similar
setting msi/6147, and at the moment it is an accurate SDRAM
detection that keeps me occupied. Uwe Hammer's code is  tied
down by a handful presumptions on the amount of present SDRAM.
My detection works, but elfboot dislikes the result so far!

Best regards for now,

Mats E Andersson


On Fri, 05 Sep 2008 17:54:59 +0200, Joseph Smith <joe at settoplinux.org> wrote
>On Fri, 5 Sep 2008 10:39:02 -0400, "Corey Osgood" <corey.osgood at gmail.com>
>wrote:
>> On Fri, Sep 5, 2008 at 8:09 AM, Joseph Smith <joe at settoplinux.org> wrote:
>>>
>>>
>>>
>>> On Thu, 4 Sep 2008 23:27:50 -0400, "Corey Osgood"
>> <corey.osgood at gmail.com>
>>> wrote:
>>>> On Wed, Sep 3, 2008 at 1:26 PM, Mats Erik Andersson
>>>> <mats.andersson at gisladisker.se> wrote:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> I have been experimenting with an algorithm to detect
>>>>> and register with the northbridge i440bx the correct
>>>>> amount of sdram present. A C-coded version is appended
>>>>> to this message. Feel free to comment on the method.
>>>>>
>>>>> In the actually working code, I had to split the
>>>>> algorithm into a lower and an upper part, in order
>>>>> not to run out of internal registers under romcc,
>>>>> but the idea remains the same.
>>>>>
>>>>> Since there are also some later stages where I have
>>>>> not understood how the previous author hard coded
>>>>> a single 64MB bank,  I presently achieve a running
>>>>> system only when I dynamically detect a distribution
>>>>> identical to what was earlier hard coded.
>>>>>
>>>>> My detection works with any combination of 0MB and
>>>>> 64MB in two rows for DIMM0 and DIMM1.
>>>>>
>>>>> Question: In case an sdram device has rows of mixed
>>>>> sizes, can one depend on the larger density being
>>>>> in row zero, and the smaller content in row one?
>>>>
>>>> Yes. The spd spec assumes the larger row will be row 0, any stick that
>>>> didn't wouldn't follow the standard. At least, that was my
>>>> understanding of it.
>>>>
>>> This can get a little confusing, when you are talking about rows, do you
>>> mean banks? Or actuall sdram slots?
>> 
>> Banks, I assume, all this terminology gets me confuseded. I'm pretty
>> sure Mats was talking about each side of the slot/ram pcb.
>> 
>>> As far as it goes with rows/banks, most intel boards only support
>>> asymmetrical sdrams so if the dimm has two sides the second side has to
>>> equal the first side.
>> 
>> You mean "only support symmetrical sdrams". IIRC, i810 supports
>> asymmetrical dimms, but I can't remember...
>> 
>> -Corey
>> 
>>> As far as sdram slots any combination should work as
>>> long as it follows the the northbridge criteria. You can look at the
>> i830
>>> raminit.c, it has a pretty clever way to detect dimms, and it works
>> every
>>> time no matter what the combination. By the way Uwe was the original
>> author
>>> of the i440bx code. Hope that helps.
>>>
>Right, symmetrical sdrams, sorry for the slip of toung. And yes to Mat's
>question, in the case of a asymmetrical dual-sided DIMM the first side will
>always be larger. But that should not matter, if your code is calculating
>on a per side/bank basis, I mean it should be able to detect the size of
>each side/bank, and if it is dual-sided, and add the two sides/banks
>togethor to give you the total size. As far as initailization goes, each
>side/bank needs to initalized seperatly... that's where it can get a little
>tricky. That's also why it is important to calculate memory on a per
>side/bank basis....
>Hope that helps.
>