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).
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).
-
Thomas Jourdan