[coreboot] [patch][v2]:fam10 microcode
Maximilian Thuermer
Maximilian.Thuermer at stud.uni-karlsruhe.de
Tue Jun 16 12:07:10 CEST 2009
Ward Vandewege schrieb:
> Hi Marc,
>
> On Mon, Jun 15, 2009 at 04:14:32PM -0600, Marc Jones wrote:
>
>> Very good catch. I am suprised we didn't see this sooner.
>>
>> The bug is that the code was always updating the passed value to the
>> next link offset even when it was on the requested link (cap_count). I
>> think that your patch has a slight problem in that it skips the CapID
>> and CapType check on the first link, link_no == 0.
>>
>> Attached is a slightly different fix (untested). I think that this
>> function could be rewritten to be more clear but this is what you get
>> when tying to keep code similarity when going from asm to C.....
>>
>> Please review and test.
>>
>
> This does not appear to fix the hang for my board. Here's a boot log with
> lots of register dumping enabled:
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-ae.cap
>
> And here's one without the very lengthy dumps:
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-af.cap
>
> I see very little difference with the older dumps.
>
> Thanks,
> Ward.
>
>
Hi Ward,
its hard to tell by the logs. I am not familiar with the board topology.
However, if I read
the output correctly, the code seems to perform alright on the first but
not on the second
CPU. I went through our code patches and discovered that there may be an
additional fix
you might need to incorporate in order to get it working.
The AMD_checkLinkType procedure only checks for gangend/unganged, HT1
vs. HT3
and so forth, but omitts a check as to whether the link was initialized
correctly (i.e.present device,
no CRC errors on the link, the like).
We added a procedure checking bit no. 4 and 5 of the link control
register whether the link was
initialized correctly and didnt suffer a link failure. The procedure is
called just before the HtSetPhyRegister
function is executed. I attached the procedure to make it clear - not a
diff file because this should normally
be contained somewhere in the checkLinkType function (up until now, it
was just a quick hack sort of).
Check if this reports your link1 on cpu1 unconnnected. It should solve
your problem then. Good luck,
Maximilian
/**
* AMD_checkLinkInitialized: check whether HT links are initialized
correctly
*/
BOOL AMD_checkLinkInitialized(u8 node, u8 link, u8 regoff)
{
u32 val;
val = pci_read_config32(NODE_PCI(node, 0), regoff + 0x18);
val &= 0x02; // link init complete
if (val == 0)
{
//printk_debug("Link %d on node %d NOT active\n", link,
node);
return FALSE;
}
else{
//printk_debug("Link %d on node %d active\n", link, node);
val = pci_read_config32(NODE_PCI(node, 0), regoff +
0x04); // ht link control reg
val = ((val & 0x30) >> 4); // bit 4 and 5
if(val = 0x10){ // init complete and no link failure
//printk_debug("Link %d on node %d has completed
init has no link failure\n", link, node);
return TRUE;
}
else
{
//printk_debug("Link %d on node %d failed to
initialize\n", link, node);
return FALSE;
}
}
}
More information about the coreboot
mailing list