On Tue, Jun 16, 2009 at 12:48 PM, Ward Vandewege <[email protected]> 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<[email protected]> 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 <[email protected]> > > Acked-by: Ward Vandewege <[email protected]> > > Thanks, > Ward. > Did you test with defaults.h errata patch as well? Can you ack it too? r4358 Marc -- http://marcjonesconsulting.com
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
