Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)

[Scott Duplichan]

-----Original Message-----
From: Carl-Daniel Hailfinger [mailto:[e-mail]] 
Sent: Wednesday, November 03, 2010 01:14 PM
To: Scott Duplichan
Cc: [e-mail]
Subject: Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)

]Hi Scott,
]
]I am not totally convinced that all changes are a net win.

Hello Carl-Daniel,

Thanks for looking at it. The strategy I used is to try to make the code
match the current AMD CIMx code as closely as possible. The existing RS780
code is based on an older CIMx version that does not support the family 10h
processor. I actually did many experiments with a reference BIOS as a way
to find what parts of the code are essential for getting Win7 booted. It is
interesting to know that much of the code is not needed for Win7 boot or
even for video playback using windows media player. An example is the code
that copies some of the processor memory controller settings to the RS780.
What is this code for then? Possibly it becomes important for some directX
or 3D operation that I did not exercise. I did not test any 3D application.

]On 03.11.2010 05:29, Scott Duplichan wrote:
]> (Re-submitting with correction to GFX debug bar setup procedure needed
]> for use with AMD family 0Fh processor).
]>
]> This patch solves crashes and BSODs that occur when booting Win7 with
]> AMD RS780 uma graphics. Tested with frame buffer sizes 64m through 1GB
]> by running dxdiag and Windows media player at 1600x1200 true color.
]> Additional changes needed to boot Win7 on Mahogany_fam10 will follow.
]>
]> -- Enable and program the debug bar as required by the ATI graphics driver.
]>    First, make the debug bar writable and allow resource allocation code
]>    to program it. Once programmed, enable its operation.
]>   
]
]Good.
]
]
]> -- Disable the family 10h processor mmconf while the RS780 mmconf is in use.
]>   
]
]I thought the family 10h processors need their own MMCONF for some
]configuration accesses. If this disable happens after all such config
]writes are done, I'm OK with it.

The family 10h mmconf is disabled only temporarily, then restored to its
previous state. I added this code because that is how the current CIMx
code does it.

]> -- Make strap programming more closely follow the reference BIOS.
]>   
]
]Good.
]
]
]> -- Disable PCIe bar 3 after using it.
]>   
]
]This one is something I have reservations about. Isn't PCIe BAR 3 the
]one via which MMCONF accesses are done? How is MMCONF going to work
]after that?

Of the two reference BIOS binaries I can boot, neither appears to leave
PCIe bar 3 enabled. I see zeros there after booting, although I am not
100% sure this means zero is its real value. Yet on the two reference BIOS
images, along with the patched coreboot, I can still see the RS780 at
mmconf+0. I assume the family 10h processor sends mmconf requests to
the HT link if the address is not that of an internal device. I don't
know how it works for family 0Fh processors.

The original coreboot RS780 code intended to disable BAR 3 after using
it. The code comment reads, "We should disable bar3 when we want to exit
rs780_enable, because bar3 will be remapped in set_resource later".
However, the call to the disable function was removed and replaced by
this comment: "Don't call disable_pcie_bar3(nb_dev) here, otherwise the
screen will crash". I debugged this problem and found the disable function
set the bar to zero, but did not disable it. So legacy video MMIO writes
were being claimed by bar 3 and not reaching the video function. The patch
corrects this problem and adds back the function call to disable bar 3 after
PCIe training is complete. The reason I even looked at this code in the
first place is this. With the unpatched code, the PCI resource allocation
code finds bar 3 writable and assigns it a base address. In my case it
assigned C0000000. This C000000 range is unusable because it is not the
range set aside for mmconf. I have mmconf at F8000000.

In addition, I noticed the mahogany_fam10 and mahogany projects have no
MCFG table, so Windows will never use mmconf for PCI config access. This
is an area I would like to study more, but any improvement should probably
be done in a separate patch. It is interesting to know that Microsoft
planned for mmconf and the ACPI MCFG table to be required for Windows Vista.
The early beta editions required it. But it proved too much trouble and
the requirement was removed. The requirement was not added back for Win7.
I don't know if it is planned for Win8.

]> -- UMA size is no longer hardcoded.
]>   
]
]Nice.
]
]
]> -- Disable write combining for all steppings to eliminate stability problem.
]>   
]
]This may have a performance impact, right? Do you know if any steppings
]with stable write combining exist?

Write combining should only be disabled for the early steppings. Why
I have to disable it for A13 is an unsolved problem. Yes, I would assume
there is a performance impact. On the otherhand, using the ATI driver with
write combining disabled still gives a big performance boost when compared
to the generic vga driver. I would like to solve this problem, but have run
out of time for the moment.

]> -- Correct task file data.
]> -- Improve the accuracy of the Atom table that passes information to the driver.
]>   
]
]Yes, that's definitely needed.
]
]
]> Signed-off-by: Scott Duplichan 
]>   
]
]I think the patch looks good, but I'd like a few answers before I ack it.
]
]Regards,
]Carl-Daniel