--- Quote Start ---
I did reduce the BAR sizes to 1MB without changing anything and there was a dmesg line that indicated the same but at the end the resource collision message was still the result. The system is an ARM 32 bit system ...
--- Quote End ---
As a debug "tool", I'd try booting the board in an x86 host and see what the Linux messages are on that machine. The "problem" may not be due to your PCIe setup, but due to the PCIe configuration logic in the ARM bootloader.
--- Quote Start ---
I traced the kernel source back to a resource allocation section which I believe must be responsible for setting the resource->start and resource->end values. ... later on in mach-msm the pcie.c code run through a 0 .. 6 for loop examining the start and end values for each resource. The fail is where the start value is 0 which I am able to see via a printk. The index vale in the for loop was 0 ... and I interpreted that at the BAR0 resource but may be mistaken.
--- Quote End ---
Sorry, I haven't dug around in that code. The place to look might actually be in the bootloader. If you boot to U-Boot, then you should be able to browse the PCIe devices.
--- Quote Start ---
I will run with and without pre-fetching on BAR0 and see what happens .
--- Quote End ---
I have not seen any hosts have problems with PCI/PCIe BARs marked as pre-fetchable versus not. I typically make the regions pre-fetchable and then make sure there are no read "side effects".
--- Quote Start ---
BTW, 1BM isn't mach menory per BAR. The system memory map allocates 128MB of space for PCI ... That seems a fair bit for the BAR's and possibly ROM ... but I ca see that 4GB is too large and the dmesg output indicate that.
--- Quote End ---
Type lspci on your host PC and look at the BAR sizes. I doubt you will find many with large BAR sizes.
The BAR regions allow host CPU access, and that access is typically terribly low performance. All of your "real work" should be done using DMA, and the DMA controller usually exists on the peripheral board, and the peripheral board needs to have bus master capability. The DMA controller can access/generate 32-bit and 64-bit PCIe addresses, so it can "see" the complete memory map of the PCIe segment it resides on.
Another use for BARs is as a window, eg., you can have a BAR with control registers and another that is the "window", and via the control registers you can set a base address that defines where the "window" looks. I have PowerPC processor boards where I can use a 1MB BAR to copy FPGA images of many MB to DDR memory and then run PowerPC DMA controller tests. The key is that a large BAR is not needed to access all of the memory on your board if you just want to "poke" around.
Cheers,
Dave
Honored Contributor
