[coreboot] [patch][v2]:fam10 microcode

[Maximilian Thuermer]

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;
                }
        }
}