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.
AFAICS, for all cores the MSR enabling MMCONF is programmed very early in the romstage. So second option for failure is there exists cases where IO must be used instead of MMCONF, but I could not find such documentation yet.
I hope Dennis can reproduce the failure log and post it in the next few days.
Kyösti
On Thu, Dec 12, 2013 at 7:02 AM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
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.
AFAICS, for all cores the MSR enabling MMCONF is programmed very early in the romstage. So second option for failure is there exists cases where IO must be used instead of MMCONF, but I could not find such documentation yet.
I hope Dennis can reproduce the failure log and post it in the next few days.
Which devices weren't working? IIRC, on old AMD processors rev E and maybe rev F the northbridge config space couldn't be accessed by MMCONF -- only the cf8/cfc method.
-Aaron
* 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
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
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
On 12/13/2013 01:34 AM, Stefan Reinauer 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
Yet we have had commit 032c23db for 5 months:
intel/i945: Use MMCONF_SUPPORT_DEFAULT
Change all PCI configuration accesses to MMIO on all boards with i945 chipset. To enable MMIO style access, add explicit PCI IO config write in the bootblock.
I remember a week or so after this was merged you made that comment about i945 on a related change. I requested literature reference or a test case to see if I should revert. I got neither and the revert never took place.
Until you are more specific on your statement, I am reading it as follows:
Stefan added 'select MMCONF_SUPPORT_DEFAULT' on a mainboard with i945 and the board did not boot.
I am not saying yout statement is incorrect, but how about some argumentation?
Kyösti
* Kyösti Mälkki kyosti.malkki@gmail.com [131213 11:29]:
Yet we have had commit 032c23db for 5 months:
intel/i945: Use MMCONF_SUPPORT_DEFAULT
Change all PCI configuration accesses to MMIO on all boards with i945 chipset. To enable MMIO style access, add explicit PCI IO config write in the bootblock.
I remember a week or so after this was merged you made that comment about i945 on a related change. I requested literature reference or a test case to see if I should revert. I got neither and the revert never took place.
Unfortunately I can not provide literature references; I worked on that chipset 5+ years ago. Here are some of the reasons..
- I never actually saw this behavior _documented_ anywhere - I received documentation under NDA - I have since changed jobs and had to destroy all documentation received through my previous employer
You should be able to use any i945 board to test that, however. For the reasons above, I also don't have access to that hardware anymore, so I can't do the testing for you.
Until you are more specific on your statement, I am reading it as follows:
Stefan added 'select MMCONF_SUPPORT_DEFAULT' on a mainboard with i945 and the board did not boot.
It might even boot but it will be missing half of the hardware setup since the device probing mechanism won't see the devices.
I am not saying yout statement is incorrect, but how about some argumentation?
It's really purely something I saw on hardware and I remembered. So I shared it. If you need proof, we will need to wait and see if anybody is actually still using this chipset in the future. I'm also not sure if that behavior was specific to the model of the i945 chipset used in those systems back then (Kontron 986LCD-M iirc, but it might have been the getac or roda, too where I ran those tests)
Hope this helps.
Stefan
On Fri, Dec 13, 2013 at 2:29 AM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
Yet we have had commit 032c23db for 5 months:
which may mean, only, that the commit broke some things and nobody hit those things until 5 months later?
Which is not at all unusual with a change of this type. It's why we prefer that commits that are this far-reaching come with some amount of testing. That patch changed 7 mainboards; which of them were tested?
I remember a week or so after this was merged you made that comment about i945 on a related change. I requested literature reference or a test case to see if I should revert. I got neither and the revert never took place.
It pays to listen to Stefan on matters such as these :-)
There are at least two reasons that your request might not have been satisfiable. - the public docs and the hardware disagree (very common) - the public docs and the NDA docs disagree (this is very common) and the vendor knows it (also really common)
Until you are more specific on your statement, I am reading it as follows:
Stefan added 'select MMCONF_SUPPORT_DEFAULT' on a mainboard with i945 and the board did not boot.
And sometimes that's about as good a diagnosis as you can get.
Expecting anything more is not always realistic. That's what makes firmware so hard, sometimes.
Meanwhile, we have a commit that broke some hardware. What do you want to do about it? I agree with Aaron, things might need to be tweaked, but ... who's got that old hardware, and the time to do it? Do you have a board of that ilk and the time to figure it out?
How do you intend to resolve the problem caused by this commit?
ron
-
Aaron Durbin -
Kyösti Mälkki -
ron minnich -
Stefan Reinauer