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
<[email protected]> wrote:
* Kyösti Mälkki <[email protected]> [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: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
