On Sun, Oct 17, 2010 at 11:17 PM, Scott Duplichan <sc...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot