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

[Ward Vandewege]

On Tue, Jun 16, 2009 at 11:16:16AM -0600, Marc Jones wrote:
> On Tue, Jun 16, 2009 at 4:07 AM, Maximilian
> Thuermer<Maximilian.Thuermer at stud.uni-karlsruhe.de> 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,
> 
> 
> Maximilian,
> 
> You found another bug. This one in checkLinkType. It checks the
> connect, init complete, and type but continues on regardless if the
> link is initialized. The caller expects the return value to be 0 is
> there was any problems with the link. Yeah, that is bad...
> 
> I don't think that you need the CRC errror checking at this point (but
> it wouldn't hurt). I think that should be handled in the HT init code
> and only the init
> 
> Here is an updated patch (untested as usual).

Here's a boot log:

  http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-am.cap

This patch now exhibits the same behaviour as Maximilian's two patches: no
more hang at initialization of CPU1, but a soft reset a little futher down. I
guess we're not quite there yet, but this is definitely a step in the right
direction.

> Signed-off-by: Marc Jones <marcj303 at yahoo.com>

Acked-by: Ward Vandewege <ward at gnu.org>

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator