In drivers/pci/setup-res.c pci_claim_resource() this message means these PCI devices claim those memory regions but the PCI-PCI bridge between the device and the CPU – maybe just the host bridge – are not set large enough to include that memory.

In drivers/pci/setup-res.c pci_claim_resource() this message means these PCI devices claim those memory regions but the PCI-PCI bridge between the device and the CPU – maybe just the host bridge – are not set large enough to include that memory.

−

That it mentions prefetchable memory is kind of minor: it's an address that requires 64-bit decoding, and it's an address that can be prefetched, but that's just the way the PCI device BAR is set.

+

That it mentions prefetchable memory is kind of minor: it's an address that requires 64-bit decoding, and it's an address that can be prefetched, but that's just the way the PCI device BAR is set. If the memory is prefetchable, it must also use 64-bit decoding. Prefetchable memory is the most efficient, so unless there are memory-mapped registers of a particular kind, it makes sense to always use 64-bit prefetchable memory.

−

TODO: put a PCI device list here

+

Here's a really bad PCI Device Listing:<pre><nowiki>

+

0:00.0 1022:1410 Host Bridge

+

0:01.0 1002:9993 ATI Radeon HD 7480D

+

0:01.1 1002:9902 ATI Radeon HDMI Audio

+

0:02.0 1022:1412 PCI-PCI bridge PCIe root port to integrated graphics

+

PCI-PCI bridge: bus 0 to bus 1

+

1:00.0 1002:954f ATI Radeon HD 4300/4500

+

1:00.1 1002:aa38 ATI Radeon HDMI Audio

−

I think the fix is to either set up the PCI-PCI bridges so the memory can be accessed, or remap the PCI device so the memory is within what the bridge will forward.

'''0:02.0: mem 0xb0000000-0xbfffffff 64bit pref''' This PCI device is just a PCI-PCI bridge, but the memory is routed through this to 1:00.0. Once the problem with 1:00.0 is fixed, the problem with 0:02.0 will be fixed.

+

+

It might be that because 1:00.0 is the on-chip VGA it is not correctly set up on the host bridge. Or maybe 0:02.0 needs to map the addresses.

+

+

'''0:15.1: mem 0xc0000000-0xc00fffff 64bit pref''' This PCI device is also a PCI-PCI bridge, so the problem is really at 4:00.0

+

+

There are two memory regions on the RTL8168/8111 card, and they need to be mapped.

+

+

I'm confident coreboot already has code to perform these mappings, so this might be only a correction in the devicetree file.

In drivers/pci/setup-res.c pci_claim_resource() this message means these PCI devices claim those memory regions but the PCI-PCI bridge between the device and the CPU – maybe just the host bridge – are not set large enough to include that memory.

That it mentions prefetchable memory is kind of minor: it's an address that requires 64-bit decoding, and it's an address that can be prefetched, but that's just the way the PCI device BAR is set. If the memory is prefetchable, it must also use 64-bit decoding. Prefetchable memory is the most efficient, so unless there are memory-mapped registers of a particular kind, it makes sense to always use 64-bit prefetchable memory.

0:02.0: mem 0xb0000000-0xbfffffff 64bit pref This PCI device is just a PCI-PCI bridge, but the memory is routed through this to 1:00.0. Once the problem with 1:00.0 is fixed, the problem with 0:02.0 will be fixed.

It might be that because 1:00.0 is the on-chip VGA it is not correctly set up on the host bridge. Or maybe 0:02.0 needs to map the addresses.

0:15.1: mem 0xc0000000-0xc00fffff 64bit pref This PCI device is also a PCI-PCI bridge, so the problem is really at 4:00.0

There are two memory regions on the RTL8168/8111 card, and they need to be mapped.

I'm confident coreboot already has code to perform these mappings, so this might be only a correction in the devicetree file.