On Wed, Mar 18, 2009 at 8:30 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 17.03.2009 23:27, Carl-Daniel Hailfinger wrote:
The Pistachio and DBM690T ACPI code uses MMCONFIG to access southbridge PCI config registers. This fails because we explicitly disable MMCONFIG accesses with disable_pcie_bar3(). The comments in the code state that coreboot is expected to reenable MMCONFIG, but that never happens.
This patch is a totally ugly workaround, but it fixes the ACPI code for me.
[...] Note that the broken version tries to access memory above 4 GB. The correct version accesses SATA_BAR5 instead.
I don't know the correct place to re-enable MMCONFIG access.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Surprise! It seems this patch has serious WTF style side effects:
- It will cause the onboard ethernet to fail (no MAC address, still
unresponsive even after manually setting the MAC address). Unexplained PCI config changes are: Cache line size 64->32 bytes, MaxReadReq 4096->512 bytes.
- It will change the PCI subsystem ID of some devices. Surprisingly, the
subsystem IDs are strange without the patch, so this is a fix, but my earliest successful boots with coreboot were correct as well. Needs to be investigated further.
This must be why they said to use MMConfig accesses whenever possible. :)
Here's my 2 cents: 1. Overwrite read resources so it doesn't touch your MMConfig BAR (sizing it would not be good) 2. Overwrite set_resources so that it: a. disables MMConfig accesses b. writes the new value to the MMConfig BAR c. enables MMConfig accesses
Then everywhere else you can use MMConfig accesses. Enable them as early as possible.
Thanks, Myles