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

Ward Vandewege ward at gnu.org
Tue Jun 16 15:54:08 CEST 2009

Hi Maximilian and Marc,

On Tue, Jun 16, 2009 at 12:07:10PM +0200, Maximilian Thuermer wrote:
> 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,

I think this helps. Have a look at how I modified init_cpus.c:


Is that what you intended?  Here's a boot log


As you can see, it gets past the second CPU initialization, which is great.
However, it soft resets itself a little further - but that's after (at least)
two cores start to talk at the same time, so perhaps that's a different
problem? Or maybe I didn't implement that call to AMD_checkLinkInitialized

I also tested with Marc's patch and your second one on top. Here's


And a boot log:


The behaviour is different - here, booting hangs after it prints 'Start node
01 done.'

Any further thoughts?

Ward Vandewege <ward at gnu.org>

More information about the coreboot mailing list