[coreboot] Possible bug in resources allocation

[Thomas Jourdan]

My mail was sent a little bit too fast.

If someone has a patch, I can test quickly.

Regards,
Thomas

Le dimanche 23 novembre 2008 à 18:57 +0100, Thomas Jourdan a écrit :
> Hi guys
> 
> I'am using coreboot v2 with a board based on an Intel E7520 and ESB6300.
> It works fine but I think there is a bug in the resources allocation
> algorithm. 
> 
> In src/northbridge/intel/e7520/northbridge.c, the function
> mc_read_resources defines a fixed memory resource. Its base is
> 0xe0000000, and its size is max_bus * 4096 * 256. If you have a look in
> the E7520 datasheet, this is the Enhanced Configuration Memory Address
> Map (3.4.2, page 40) :
> 
> "Configuration software will read this register to determine where the
> 256 MB range of memory addresses resides for enhanced configuration.
> This register defaults to a value of Eh, which corresponds to E0000000h.
> It is not intended that this value is ever changed by BIOS."
> 
> I have a PCI card that reclaims two regions of memory for a total of 320
> MB (256 + 64). This card is behind the "Hub Interface to PCI
> Bridge" (D30:F0) of the southbridge (ESB6300), which acts like a PCI
> bridge. During the enumeration, one memory window of my PCI card will be
> mapped in 0xe000000, despite there is already a fixed resource here.
> 
> Then few days ago, I saw a patch on the mailing list when the Kontron
> 986LCD-M was added. It is "[PATCH 5/6] Changes required to the device
> allocator". It adds a new configuration option
> "CONFIG_PCIE_CONFIGSPACE_HOLE" which seems to be exactly what I need. 
> 
> In src/devices/device.c, the PCIe config space hole is hardcoded to
> 0xf0000000. I changed it to 0xe000000 in my case :
> 
> #if CONFIG_PCIE_CONFIGSPACE_HOLE
> #warning Handle PCIe hole differently...
> 	if (base >= 0xf0000000 && base < 0xf4000000) {
> 		base = 0xf4000000;
> 	}
> #endif
> 
> to
> 	if (base >= 0xe0000000 && base < 0xf0000000) {
> 		base = 0xf0000000;
> 	}
> 
> But it still doesn't work. The PCI bridge will need a memory resource of
> 320 MB. During the resources allocation, base will be set to 0xe0000000
> at the beginning of compute_allocate_resource. Before the test the patch
> added, base was set to 0xf4000000. So it doesn't pass the test and is
> not modified. The computed region overlaps the MCH fixed region.
> 
> I'm not familiar enough with the resource allocation algorithm to send a
> patch. So far, my workaround is to move the PCIe config space hole to an
> unused area (which may not always work depending PCI cards).
> 
>