[coreboot] [PATCH] Fix RS690 MMCONFIG access

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Mar 19 01:13:12 CET 2009


On 18.03.2009 15:30, Carl-Daniel Hailfinger 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 at 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.
>   

Ward, can you confirm this bug on the M2A-VM? It seems that if I enable
the workaround, the RTL8169 memory BAR becomes inaccessible and reads
return 0xff. Absolutely no idea why. I speculate that it will be helpful
to run lspci with/without the workaround before and after any RTL8169
driver is loaded.


> - 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.
>   

Looks like the non-designation of the MMCONFIG area causes the kernel to
stomp on it. Sometimes.


> How do I dump the PCI config space of all available devices directly
> before passing control to the payload?
> dump_pci_devices() uses the early PCI functions (device_t is u32) and is
> thus not suitable for code compiled with device_t = struct device *.
>   

Ron?


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list