[coreboot] pci resource allocation overlaps config_mmconf_base_address

Myles Watson mylesgw at gmail.com
Mon Oct 18 17:34:22 CEST 2010


On Sun, Oct 17, 2010 at 11:17 PM, Scott Duplichan <scott at notabs.org> wrote:
> ]> 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.
> ]
> ]Stefan
>
> 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.
This is true.  You can use a hard-coded address until that point,
though.  There are many resources that must do this.

> 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.
It only has to be fixed until the allocation is done.  It would
require a little care when setting the new address, but I think it's
the right way to do it.

> 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.
It causes a problem if the alignment doesn't match up well and leaves
a large hole.  How big is the MMCONF space? 256 MB?  What's the
highest you can put it without running into the other fixed resources?

> Why does the current code for handling fixed resources allow the mmconf
> space to get allocated to a PCI device?
Because there is no fixed resource defined for it?

> 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
> PCI_DOMAIN.
We can change the code to scan the entire tree if that makes more sense.

> Right now, each 'pci domain n' is treated as if it has a completely
> private resource address space.
I thought that was the definition of a PCI domain.

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

Does the resource belong in the lapic cluster?

Thanks,
Myles




More information about the coreboot mailing list