On 12/13/2013 03:46 AM, ron minnich wrote:
Which is why I always worry about global changes of this sort when they can't be tested.
Things like this that *should* work, and look very reasonable, can at times get nasty.
ron
To keep the conversation on amdfam10: I was relying on information in commits 90ca14d7 (and its fix 79cfe7e0):
Use MMCONF for all AMD family 10 CPUs.
This fixes problems in AP init when multiple APs are trying to access PCI config space. All Fam10 CPUs setup and support MMCONF.
That patch would have originally failed if MMCONF_SUPPORT_DEFAULT behaved they way it was meant to, to use MMCONF unless IO is explicitly defined.
Kyösti
On Thu, Dec 12, 2013 at 3:34 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
- Kyösti Mälkki kyosti.malkki@gmail.com [131212 16:02]:
Hi
After commit 872c922 there is some trouble on PCI configuration access with Asus M4A785-M. This could apply to other amdfam10 too, although I have not yet received such reports.
As the commit message stated, I had discovered that in the beginning of ramstage all PCI configuration access used the IO (0xcf8) method even though Kconfig specified MMCONF_SUPPORT_DEFAULT which should imply all PCI config access is done with MMCONF unless IO is explicitly requested.
Not sure if this is relevant, but on i945 not all PCI devices are visible in MMCONF space. So enabling MMCONF_SUPPORT_DEFAULT there will break the system.
Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot