[coreboot] pci resource allocation overlaps config_mmconf_base_address

Scott Duplichan scott at notabs.org
Mon Oct 18 07:17:34 CEST 2010

]> Hi all,
]> Scott, thanks on working on that! The resource overlap is bit pitty -
]> it belongs to style - "Oh I haven't thought of that".
]I think this was heavily discussed a while back, and lead to some
]naughty work arounds in the i945 code. because having such big a "hole"
]lead to no resources being placed after the MMCONF area. Ther should be
]a better way to do it. Have to admit I have not particularly checked out
]the k8t890 code yet. My experiments with allocating a resource for it in
]the i945 northbridge code didn't keep the resource allocator from
]putting other stuff on top of it, mainly because of the hierarchical way
]the resource allocator works. Any insights are highly welcome.

Thanks for the suggestions everyone. I like the k8t890 method, however
there is a concern. I think the dynamically obtained mmconf base address
would not be known or programmed until fairly late. But using mmconf
very early to access config space was the key change that solved the
unreliable AP startup on my project. The unreliable AP startup problem
was caused by simultaneous core access to cf8/cfc. I think there is a
real value in knowing the mmconf base very early, and that requires a
fixed resource assignment.

I found a reasonable scheme for handling fixed resources is already in
place. This is why the local apic space at fec00000 is never allocated
to a PCI device. Yes, the code allocates from a single range only. But
it knows to avoid fixed resources. As long as some care is used when
choosing a fixed resource location, the existing scheme seems fine.

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

Right now, each 'pci domain n' is treated as if it has a completely 
private resource address space. The real problem is that the resource
assignments of 'lapic cluster n' are completely ignored when assigning
resources to a pci domain. One solution might be to add an argument to
function avoid_fixed_resources that allows passing in apic cluster
in addition to the pci domain that is already passed in. Then
avoid_fixed_resources could consider the apic cluster resources when
adjusting its allocation limits to avoid fixed resources. I could
prototype something like this if it sounds reasonable.


More information about the coreboot mailing list