Hello,<br>I am trying to bring up linux kernel 2.6.14 on a system using MPC 8343E and am having issues with the PCI resource allocation in the kernel. I saw these messages:<br>.............<br>PCI: Cannot allocate resource region 0 of device 0000:00:
00.0<br>PCI: Cannot allocate resource region 2 of device 0000:00:00.0<br>PCI: Failed to allocate mem resource #2:80000000@0 for 0000:00:00.0<br><br>After digging into the codes, I realize that the PCI subsystem scan the bus and reading the BARs in the CPU PCI controller, which give the region 1 from 0x0 to 0x000FFFFF and region 2 from 0x0 to 0x7FFFFFFF. And the values I assign to the bridge resource in calling pci_init_resource during setup hose is 0x80000000 - 0x9FFFFFFF (I got this values from the mpc834x_sys.h).&nbsp; So I just extend the bridge resource to 0x70000000 - 0xFFFFFFFF to cover all 2 regions in the 2 BAR and this seems to get rid of the above messages. However this would cause other platform devices to fail to claim its resources, 
<br><br>fsl-gianfar.1: failed to claim resource 0<br>unable to register device 0<br>fsl-gianfar.2: failed to claim resource 0<br>unable to register device 1<br>fsl-i2c.1: failed to claim resource 0<br>unable to register device 2
<br><br>Could anyone tell me how these PCI resource work and how to resolve this conflict?<br>And my other questions are&nbsp; why is the region 2 in the mpc8343E such huge and what is it used for? <br>Also Why the kernel looks into the CPU PCI controller? because as I understand, in the hose setup step in platform initialization, the host bridge is skipped while other PCI devices would be probed and have their BARs assigned the address range to use ( in function pciauto_bus_scan in arch/ppc/syslib/pci_auto.c )
<br><br>One more question, are these BARs in the PCI controller related with the PCI inbound and outbound mapping of the PCI interface? Do the regions in BAR need to match/derive from the inbound/outbound address mapping?
<br><br>Thank you,<br><br>Luong Ngo<br>