No, but it adds yet more duplicated code. Since in most cases all
memory init code can figure out what the population map looks like on a
channel bases, pass that info to the board. The board module can
swizzle the population map by channel into population map by physical
dimm slot (since that mapping may be different on a per board level).<br>
<br>
-San<br>
<br><br><div><span class="gmail_quote">On 10/28/05, <b class="gmail_sendername">Eric W. Biederman</b> <<a href="mailto:ebiederman@lnxi.com">ebiederman@lnxi.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
San Mehat <<a href="mailto:san@google.com">san@google.com</a>> writes:<br><br>> Reworking the attribute is actually causing a huge pain in the ass with<br>> relocations it looks like. I'm going to see if i can have the amdk8 MCT code
<br>> return the dimm_mask information back to the board via sdram_initialize().<br>><br>> I could either just have sdram_initialize() return a merged version of<br>> dimm_mask which would limit the number of dimms supported, or I could pass in
<br>> an additional non-static 'population' structure which i think may be better.<br>><br>> Any thoughts?.. I'm going to modify my stuff to pass in a new structure in the<br>> meantime..<br><br>Is there any reason not to simply query for the data back at the mainboard
<br>level?  It isn't like the discovery is hard.<br><br>Eric<br></blockquote></div><br>