Does anyone know what this could mean ? Jan 1 00:30:22 linaro-developer kernel: [ 1822.434579] PCI: Device 0000:01:00.0 not available because of resource collisions I have the sample SG DMA DD and a Arria V Starter Kit with a PCIe design... I altered the DD to mathc the DEVICE_ID ... I am not sure there the resource collison can be resolved. I ammume a memory map overlap at the BAR's. Thanks, Bob.

I am now adding printk's to the kernel and re-building it ... I do know where it fails but need to track back as to why the dev-> resource's are start = 0, end = 0xFFFFF, for the first resource ... where I believe each resource is a block of memory map allocated to the BAR register. To make it simple I first reduced the BAR size to be 20 bits .. from 28 bits since that amount of memory was not available in the map. I then tried making BAR 0 32 bits and not pre-fetchable. BAR 1 disabled and BAR 2 32 bits. I have now reduced to just BAR 0, non-prefetch ... I have to believe the system supports non-prefetch memory which is necessary for any control registers. The particular test that is failing is for the first dev->resource.start != 0 and dev->resource.end = 0xFFFFF. the first test fails and the printk reports a "resource collision". I need to work back to see why the start value isn't a meaningful number ... The dmesg outpus doesn't seem to have any particular errors. Any ideas on this ? Thanks BCD.

BAR registers are typically for access to small regions, eg., typically no more than 1MB regions (20-bits). Any larger than this, and a lot of PCs will not even boot, eg., your 32-bit BAR is asking for a 4GB region in the host memory map. If that host is 32-bits ... well ... that ain't going to happen :) Try smaller BAR regions and see if that helps. Ignore any arguments in favor of large BARs, that discussion can come after you resolve this issue :) Cheers, Dave

Thanks Dave, 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 ... 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 indx vale in the for loop was 0 ... and I interpreted that at the BAR0 resource but may be mistaken. Currently I have reduced to a single BAR0 (32bit address ) and I did notice there are some requirements checked before the resource allocation code does it's job ... like checks for if pre-fetching is allowed or not ... I need to check on ARM where this decision is made. in /proc/mem I do see space allocated for the memory beyond the PCIe bridge ( Synopsys IP ) The original reference design has BAR0/1 as pre-fetchable and BAR2 not ... I guess this is since BAR2 handles NIOSII IP where pre-fetching could have side-effects that we can't handle. So I will run with and without pre-fetching on BAR0 and see what happens . 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. Best Regards, Bob

--- 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

Hi Dave and team, I owe you an answer here ... I wasn't really getting anywhere adding printk messages to the PCIe kernel code so elected a different approach. I tried a $30 dual USB PCIe endpoint from Fry's and it had resources allocated just fine. I recorded the dmesg output to a text file then did the same with the Arria V starter kit board with my Gen1 X1 PCie design and again recorded the dmesg output to a text file. I then diffed the two outputs and evaluated the differences. Oh, I should say that I modified the FPAG design to match the BAR's and sizes that were showing up on the dyal USB endpoint ... it still failed with a "resource conflict" Anyhow the first difference was the Class code returned from the endpoint config space. The FPGA was returning 0x00000000, since I was not setting it to anything and the USB PCIe endpoint card returned a non-zero value indicating some serial bus endpoint. So ... I copied that class code to the FPGA design and the resources were allocated as expected. I have not traced through the PCIe kernel code to determine why a Class of 0x00000000 causes problems but the PCIe reference indicates a value of 0x00000000 indicates some early adapter so I assume the kernel code is not supporting a 0x00000000 code. I have made progress on the Linux device driver based on the 2 samples provided from Altera. I also found that the Linux I have doesn't support pre-fetchable memory attribute on the BARS. And I set the BAR0 to 32 bit address space and defined the BAR1 as 32 bit address to access the DMA controller and mail boxes for NIOS <-> ARM system ( rc ) communications . I now have IOCTL functions supporting the ARM system as a "producer" and have NIOS code to implement the "consumer" side ... I plan to add dedicated PCI order checking state machines at the output of the hard PCIe IP at the Avaon MM BAR0 output and where read completion data is mastered ... to monitor dedicated "data" coming down the BAR0 master and a dedicated "flag" pattern which will be a NIOS read completion. As a debug tool I plan to have the order tracking state machine inputs ( patterns) drive FPGA outputs to drive user LED's and be tracked by logic analyzer. Dave, on a new subject, I want to run CVP to manage the FPGA configuration from the system side ... but I also want to load the NIOS .elf or .flash code from the system side as well. Where should I go for advice on say configuring the NIOS Flash from the system side .... I believe maintaining both from the system side is the only reasonable way to manage "configuration" and "code" levels since as a manual operation it would be difficult to manage. Would it be as easy as adding a FLASH controller and having the system update the FLASH diirectly wiith a new .flash file ? Thanks, Bob.

Resource Collisions when installing PCIe DD

25 Replies

Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---

I believe you are saying the NIOS core can be released from reset or controlled via a register output to start executing the reset vector and the system ( rc ) side could do the load and reset register operation.

--- Quote End ---

The NIOS II processor is "just logic". If you hold that logic in reset, it'll do nothing until you enable it. This means that you can manipulate the memory map via PCIe, and then release the processor from reset.

I have not done this with the NIOS II processor, but I have several hundred boards with DSPs on that I use this technique with, since I can then guarantee that they are all booted with exactly the same image (served from a common NFS filesystem).

Cheers,
Dave
Altera_Forum
Honored Contributor
11 years ago
Ok many thanks ... the NIOS reset appears to be sourced via the JTAG debug module ...
I believe you indicate I need to control the NIOS reset explicitly , ie disonnect it from the JTAG debug reset and generate a reset to the system that starts once the FLGA is configured and receives the first functional clock. ?

Thanks, Bob
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
the NIOS reset appears to be sourced via the JTAG debug module ...

--- Quote End ---

Appears? It likely has an option to reset via JTAG. However, in a deployed system, that is not going to be the only way to reset the processor.

If you have not created a simulation of a NIOS II processor, then I'd recommend creating a simple design with one. Creating a simulation where you can hold the processor in reset, deassert reset and allow it to boot, and then repeat that sequence, will go a long way in helping you understand how to do it in hardware.

--- Quote Start ---

I believe you indicate I need to control the NIOS reset explicitly , ie disonnect it from the JTAG debug reset and generate a reset to the system that starts once the FLGA is configured and receives the first functional clock. ?

--- Quote End ---

Reset is "just a signal". The clocks on a board can power up, and other logic can come out of reset, eg., a PCIe endpoint can come out of reset, that end-point can be used to manipulate bits, and one of those bits can be the NIOS II processor reset signal. This provides a mechanism where you can download to the NIOS II processor boot memory over PCIe, then release it from reset, and it will boot.

Cheers,
Dave
Altera_Forum
Honored Contributor
11 years ago
Ok Dave ... so you provided an Avalon MM Master and Avalon MM Slave Modelsim testbench which was very useful.

Are you saying that the NIOS II in the simulation is the actual RTL model and it is the actual design ? I was thinking the NIOS II was a BFM with a Avalon MM Master for Instructions and Data ... If it is the actual design, then after reset is deasserted it will fetch the reset vector. That would be great. I would be very interested in a pointer or from memory, you indicated to get the system to generate a testbench and then start with that as a modification point. I would also need to initialize the FLASH memory with the actual binary code that results from programming FLASH with the *_sw.flash file .

I have made some progress based on the NIOS II reset discussion. I committed both the FPGA configuration and the NIOS software to FLASH and , powered on and the alive LED from the FPGA is flassing and the NIOS alive LED is on solid, due to PIO latch reset.
When I go to the Eclipse Run Configurations -> Target Connection -> Debug section I can deselect the Download Software button, Deselect the Reset System button and Select the Start NIOS button and the NIOS PIO led starts to flash ... I believe this is a fair indication that all I need to do is to move the NIOS Reset from the JTAG debug reset to the regulat reset or possibly have QSYS simply OR in the regular reset that goes to the other cores.

Thanks alot, Bob.
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---

Are you saying that the NIOS II in the simulation is the actual RTL model and it is the actual design?

--- Quote End ---

You can simulate a NIOS II processor;

http://www.altera.com/support/examples/nios2/exm-simulating-niosii.html

For your understanding of how the NIOS II processor boots, I would create a new design that does not include complications like PCIe, but has the processor and its boot memory, and some external I/O, one of which is a reset signal that you can toggle in your testbench. By watching the NIOS II processor buses, you will see what happens at reset. You can then change the NIOS II processor configuration and see how that affects the reset sequence. Chances are you will have an "ah-ha!" moment, and then see what you need to do for your hardware.

--- Quote Start ---

I have made some progress based on the NIOS II reset discussion. I committed both the FPGA configuration and the NIOS software to FLASH and , powered on and the alive LED from the FPGA is flassing and the NIOS alive LED is on solid, due to PIO latch reset.
When I go to the Eclipse Run Configurations -> Target Connection -> Debug section I can deselect the Download Software button, Deselect the Reset System button and Select the Start NIOS button and the NIOS PIO led starts to flash ... I believe this is a fair indication that all I need to do is to move the NIOS Reset from the JTAG debug reset to the regulat reset or possibly have QSYS simply OR in the regular reset that goes to the other cores.

--- Quote End ---

That sounds reasonable. Try it and see :)

Cheers,
Dave

Forum Discussion

Resource Collisions when installing PCIe DD

25 Replies

Recent Discussions

JTAG_UART stuck in printf

NIOS SDK SBOM/FOSS info

NiosV µC/OS-II

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"