[coreboot] Porting to Asus M4A78-EM

Scott Duplichan scott at notabs.org
Fri Dec 3 01:57:32 CET 2010

On Thu, Dec 2, 2010 at 9:17 AM, Myles Watson <mylesgw at gmail.com> wrote:
>> "Why does the current code for handling fixed resources allow the mmconf
>> space to get allocated to a PCI device? Function avoid_fixed_resources
>> calls function constrain_resources, which recursively searches the
>> device tree for fixed io and memory resources. The ioapic fixed memory
>> address is found and avoided during the recursive search because this
>> southbridge device is below the level where the search starts. On the
>> other hand, the mmconf fixed resource is added from the northbridge code,
>> and falls under 'APIC_CLUSTER: 0'. This device is not part of the search
>> for two reasons. One is that it is not at or below 'pci_domain 0' in the
>> device tree. Another reason is that its type is APIC_CLUSTER and not
> I don't see any reason not to move that resource into the northbridge
> to avoid that issue.  It's a simple fix.  Is there a good reason for
> having the MMCONF BAR in the APIC cluster?
This is what I was thinking.  Build tested only.

Signed-off-by: Myles Watson <mylesgw at gmail.com>


Thanks Myles. I tested using the Kino project. With mmconf_base_address
set to e0000000, mmconf_bus_number set to 256, and no patch, booting 
hangs in vbios init. Adding the patch allows it to boot, and I find no
bars overlapping the mmconf area. This patch seems to solve the problem
for me. If I get a chance, I will try Win7 boot also.


More information about the coreboot mailing list