Re: [coreboot] coreboot support for AMD HT3

[Maximilian Thuermer]

Scott Duplichan wrote:
> > At 1600x1200, 16-bit color is almost perfect. But the same
> > resolution with 32-bit color results in a display that jumps so
> > much it cannot be read. Why would 32-bit color make a difference?

Twice the bandwidth needed to get the graphics data out of RAM.
> > I am thinking that refreshing 1600x1200 pixels 60 times per second
> > takes a lot data, and that data has to cross the HT link. True
> > color takes more data than high color, and true color may be
> > exceeding the capacity of the cpu-RS780 link. The link is running
> > at the slowest possible setting, 200 MHz, 8-bit.

Ouch! :\ That would seem to cause the problem.

Can't say about HT3 I'm afraid.

//Peter

Hi Scott,

HT3 is all there and working perfectly as long as it is between two
CPUS or CPU and HTX expansion slot. I noticed frequencies not being set
correctly in HT init for Southbridge links, all other links seem
to run at their optimal speed. Normally, Southbridges support HT1 frequencies
up to HT1000 which should be sufficient for your problem to vanish. Either you try overwriting
the coreboot settings manually on CPU and SB side (HT Specification and BKDG
should help here) or you try to fix the problem at its root which is that the Southbridge
capability registers do not seem to get read out alright by the HT init procedures.

Best regards,

Maximilian Thuermer

coreboot support for AMD HT3

[Scott Duplichan]

]> > At 1600x1200, 16-bit color is almost perfect. But the same
]> > resolution with 32-bit color results in a display that jumps so
]> > much it cannot be read. Why would 32-bit color make a difference?
]>   
]
]Twice the bandwidth needed to get the graphics data out of RAM.
]
]
]> > I am thinking that refreshing 1600x1200 pixels 60 times per second
]> > takes a lot data, and that data has to cross the HT link. True
]> > color takes more data than high color, and true color may be
]> > exceeding the capacity of the cpu-RS780 link. The link is running
]> > at the slowest possible setting, 200 MHz, 8-bit.
]>   
]
]Ouch! :\ That would seem to cause the problem.
]
]Can't say about HT3 I'm afraid.
]
]
]//Peter
]
]Hi Scott,
]
]HT3 is all there and working perfectly as long as it is between two
]CPUS or CPU and HTX expansion slot. I noticed frequencies not being set
]correctly in HT init for Southbridge links, all other links seem
]to run at their optimal speed. Normally, Southbridges support HT1 frequencies
]up to HT1000 which should be sufficient for your problem to vanish. Either you try overwriting
]the coreboot settings manually on CPU and SB side (HT Specification and BKDG
]should help here) or you try to fix the problem at its root which is that the Southbridge
]capability registers do not seem to get read out alright by the HT init procedures.
]
]Best regards,
]
]Maximilian Thuermer

Hello Maximilian,

I debugged this problem today by comparing the coreboot HT code to that of
the reference BIOS. The problem was the BUID swap list. The reference BIOS
uses {0, 1, 0xFF, 0, 0xFF}. When I use that list, the connection becomes HT3
1.8 GHz 16-bit, same as the reference BIOS. Whth the original swap list,
execution hits a macro 'STOP_HERE'. The coreboot default is to generate no code
for that macro. We could change the default to something like printk(),die(),
though a better default swap list is needed first.

With the HT3 fix, the win7 generic vga driver problems do indeed disappear.
Video works well at 1600x1200 true color, and the (2D) performance is good.

Major known remaining problems with win7 on this RS780/SB700 board are:
1) ATI video driver still encounters a timeout which triggers a BSOD.
   Workaround: boot safe mode and switch to the generic vga driver.
2) The shutdown function does not power down the main power.
   Workaround: turn off power manually.

Tomorrow I will start distilling and posting the changes for review.
After that, I will resume work on these two remaining problems.

Thanks,
Scott

coreboot support for AMD HT3

[Marc Jones]

On Thu, Oct 14, 2010 at 10:33 PM, Scott Duplichan  wrote:
> ]> > At 1600x1200, 16-bit color is almost perfect. But the same
> ]> > resolution with 32-bit color results in a display that jumps so
> ]> > much it cannot be read. Why would 32-bit color make a difference?
> ]>
> ]
> ]Twice the bandwidth needed to get the graphics data out of RAM.
> ]
> ]
> ]> > I am thinking that refreshing 1600x1200 pixels 60 times per second
> ]> > takes a lot data, and that data has to cross the HT link. True
> ]> > color takes more data than high color, and true color may be
> ]> > exceeding the capacity of the cpu-RS780 link. The link is running
> ]> > at the slowest possible setting, 200 MHz, 8-bit.
> ]>
> ]
> ]Ouch! :\ That would seem to cause the problem.
> ]
> ]Can't say about HT3 I'm afraid.
> ]
> ]
> ]//Peter
> ]
> ]Hi Scott,
> ]
> ]HT3 is all there and working perfectly as long as it is between two
> ]CPUS or CPU and HTX expansion slot. I noticed frequencies not being set
> ]correctly in HT init for Southbridge links, all other links seem
> ]to run at their optimal speed. Normally, Southbridges support HT1 frequencies
> ]up to HT1000 which should be sufficient for your problem to vanish. Either you try overwriting
> ]the coreboot settings manually on CPU and SB side (HT Specification and BKDG
> ]should help here) or you try to fix the problem at its root which is that the Southbridge
> ]capability registers do not seem to get read out alright by the HT init procedures.
> ]
> ]Best regards,
> ]
> ]Maximilian Thuermer
>
> Hello Maximilian,
>
> I debugged this problem today by comparing the coreboot HT code to that of
> the reference BIOS. The problem was the BUID swap list. The reference BIOS
> uses {0, 1, 0xFF, 0, 0xFF}. When I use that list, the connection becomes HT3
> 1.8 GHz 16-bit, same as the reference BIOS. Whth the original swap list,
> execution hits a macro 'STOP_HERE'. The coreboot default is to generate no code
> for that macro. We could change the default to something like printk(),die(),
> though a better default swap list is needed first.
>
> With the HT3 fix, the win7 generic vga driver problems do indeed disappear.
> Video works well at 1600x1200 true color, and the (2D) performance is good.
>
> Major known remaining problems with win7 on this RS780/SB700 board are:
> ATI video driver still encounters a timeout which triggers a BSOD.
>
> Workaround: boot safe mode and switch to the generic vga driver.
> 2) The shutdown function does not power down the main power.
>   Workaround: turn off power manually.
>
> Tomorrow I will start distilling and posting the changes for review.
> After that, I will resume work on these two remaining problems.
>
> Thanks,
> Scott

Scott,

We have problems with SB HT and BUID swaplist that are not fully
understood. The swaplist was only partially implemented and needs to
be brought out to the mainboard settings. If you care to add that and
to maybe comment how the fields should be filled, that would be really
helpful.

Marc

coreboot support for AMD HT3

[Scott Duplichan]

]
]Scott,
]
]We have problems with SB HT and BUID swaplist that are not fully
]understood. The swaplist was only partially implemented and needs to
]be brought out to the mainboard settings. If you care to add that and
]to maybe comment how the fields should be filled, that would be really
]helpful.
]
]Marc
]
]-- 
]http://se-eng.com

Hello Marc,

I suppose I can give it a try. Though I have only one real board to test
with, I could try to test some others with simnow.

I have delayed posting win7 patches because I made some progress on one
of the remaining RS780/SB700 win7 problems. The current RS780 code leaves
'bar3' enabled because disabling it caused loss of video. It turns out 
this causes problems of its own. I fixed a simple bug in the bar3 disable
function and now it works. The ATI graphics driver can now operate.
Unfortunately, it still has stability problems. More debug...

Thanks,
Scott