This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/AM5728: PCIe enumeration in DSP

Part Number: AM5728

Tool/software: TI-RTOS

Hi, 

In our custom board, we have 3 ports Pericom switch on which we connected 2 Sitara processors and 1 Cyclone V FPGA:

So far, we managed to get PCIe link-up on both the AM5728. Now, I would like to perform the PCIe enumeration on the RC. Both the EP and RC code is running within the C66 DSP core. I understand the PCIe enumeration as stated in the following thread: 

I have previously implemented such procedure on the KeyStone-II device. In KeyStone-II I used the 'Configuration Transaction Setup Register' (CFG_SETUP) register to perform that operation. 

However, that register is not supported on the Sitara processor. I have read section 24.9.4.8.2.2 of the AM5728 TRM (multiple times) and don't understand exactly how this can be accomplish with the Pciev1_atuRegionConfig function.

Any help will be greatly appreciated. 

- David

  • The RTOS team have been notified. They will respond here.
  • Hi,

    What SW you run on the AM5728 RC for the enumeration? It looks like Processor SDK RTOS on C66x? The RTOS code doesn't do the enumeration. Have you consider run Linux on A15 as the Linux OS does the enumeration? The enumeration process can be seen: en.wikipedia.org/.../PCI_configuration_space

    The mentioned CFG_SETUP register applies to Keystone I/II PCIE, AM5728 uses different PCIE IP so the register is not there. I looked at the 24.9.4.8.2.2 Configuration Requests over PCIe, I believe in Linux code we should have what registers are programed for enumeartion happening. I will search and update you.

    Regards, Eric
  • Hi Eric, 

    Yes, I am using the TI-RTOS on the C66 to perform the PCIe operation. I understand the enumeration process is not provided in the PDK and I need to implement it myself. 

    We already run Linux on the A15 and we could perform the enumeration on the Linux side. But that would add a layer of complexity to our design since the all PCIe function must be done in the DSP / M4. 

    If you can point me to the Linux code that does it this would be great. 

    Regards,

    - David

  • Hi,

    You may look at the PCIE Linux driver under any recent Linux release, e.g: ti-processor-sdk-linux-rt-am57xx-evm-03.03.00.04/board-support/linux-rt-4.4.41+gitAUTOINC+968d071ce9-g968d071ce9/drivers/pci/controller/

    The AM5728x code is: pci-dra7xx.c. Function dra7xx_add_pcie_port()
    The generic code is: pcie-designware-host.c. Function dw_pcie_rd_conf().

    Regards, Eric
  • Thanks Eric for the reply.

    After looking quickly, it seems to be it would be cumbersome to reverse engineer whatever is done in the Linux Kernel to properly setup the buses with the switch.

    Do you think it would be possible to perform the following:

    - Let the linux kernel perform the enumeration, mapping the BAR to the PCIe address space
    - Boot the DSP and perform any configuration that needs to happen on each of the endpoint (I already have that logic written in the DSP for the FPGA)
    - Configure any inbound translation in the DSP
    - Setup PCIe interrupt handler in the DSP and the M4 processor

    Any reason why that wouldn't work?

    - David
  • Hi,

    If you use A15 to enumerate two seperate EPs in your system, the Linux would do the BAR mapping, Inbound and Outbound mapping, interrupt registeration to ARM GIC. For the DSP side, if you run the RTOS, it will do the same thing, except that no enumeration, and register the interrupt to C66x core. It looks that you what to use C66x to do data movement and interrupt, then you need to disable the PCIE interrupt registration in Linux. This is a mixed use of Linux and RTOS to split PCIE function, you need some trial.

    We have usage case where customer disabled PCIE totally in Linux device tree and use Linux to download a DSP image to C66x, let C66x full handle the PCIE. But it seems problematic to your case as you have two EPs in the system.

    I knew the reverse engineer of Linux code is cubersome. That folder also has the PCIE driver for Keystone II device in pci-keystone-dw.c. You can find out how the CFG_SETUP is programed there and made a comparsion the callflow to DRA7 case if any similarity.

    Regards, Eric
  • Hi Eric,

    Thanks for the feedback. Yes, our data movement and interrupt with PCIe is done in the DSP/M4 right now. We would like to keep it there so that we can use the A15 cores cycles to do something else.

    We already have a working model with a single endpoint in the C66x. But, like you said, the PCIe LLD was design with a single EP in mind.

    I will try the mixed setup next week and see if I can get it to work. The only thing I need to remove is the interrupt registration on the ARM. I can redo the inbound and outbound mapping in the DSP application.

    Regards,
    - David