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

[Marc Jones]

On Tue, Jun 16, 2009 at 12:48 PM, Ward Vandewege <ward at gnu.org> wrote:

> 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.
>

Did you test with defaults.h errata patch as well? Can you ack it too?

r4358

Marc

-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090616/02804228/attachment.html>