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:
http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-ak.c
Is that what you intended? Here's a boot log
http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-ak.cap
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 correctly?
I also tested with Marc's patch and your second one on top. Here's init_cpus.c:
http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-al.c
And a boot log:
http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-al.cap
The behaviour is different - here, booting hangs after it prints 'Start node 01 done.'
Any further thoughts?
Thanks, Ward.