[coreboot] [patch][v2]:fam10 microcode
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
Any further thoughts?
Ward Vandewege <ward at gnu.org>
More information about the coreboot