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.

PROCESSOR-SDK-J721E: Does PCIe slot 0 work on J721e EVM?

Part Number: PROCESSOR-SDK-J721E
Other Parts Discussed in Thread: TDA4VM, J784S4XEVM

Hi,

I have got a PCIe driver working under FreeRTOS on TDA4AH. However it is only properly working for the PCIe cable connected in slot 1. When I try slot 0, it succeeds link training, but will not transfer any data to the other side, which is also a TDA4AH.

I moved the PCIe window from 0x18000000 (PCIE1_DAT0) to x10000000 (PCIE0_DAT0). 

The driver sets up address translation for the data, configuration, and interrupt areas. 

I believe that the problem is to do with the memory mapping/address translation - that the address values I have are hard-coded to work with slot 1 but not slot 0.

For the Inbound Base Address for the RC (and Outbound for the EP) I have 0x70000000.

For the Oubound Base Address for the RC (and Inbound for the RC) I have 0x90000000.

Please can you explain the use of the locations as, looking at the memory map, they are assigned to other things.

Thanks,

Simon

  • Apologies, I meant TDA4VM in this query.

  • Hi Simon,

    Could you remind me if this is a custom board or a TI EVM (J784S4XEVM)? For EVM, I would like to make sure the hardware is configured correctly on top of software. If the TI EVM is used, the second PCIe slot is by default set for EP-mode instead of RC-mode. To change the slot to RC-mode, a hardware change needs to be made, for which the details of the change can be found here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1230896/faq-j784s4xevm-how-to-enable-second-pcie-slot-for-two-ssd-cards

    On top of that, this is for the Linux driver, but one device should be configured as RC and the other as EP (assuming the connection is between just two EVM), and the method to make this configuration change in software can be found here: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j784s4/08_06_01_02/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html. I would assume a similar setting needs to be done with your RTOS driver.

    As you suspect, this might be due to memory mapping/address translation, but I would like to make sure the necessary configuration for RC-mode vs EP-mode is set for the correct slots before delving into other theories. Because my suspicion of what is happening is slot 0 is configured by hardware and/or software for RC-mode, but being used as if it is in EP-mode, or something similar along that line for either slot 0 and slot 1. So I think we should make sure that whatever slot is RC is configured for RC in software and hardware, and that this is connected to the other board's slot that is configured as EP in software and hardware.

    Regards,

    Takuma

  • Thankyou very much Takuma. I did some further tests and found the following:

    The boards at both ends of the link are J721Es, not customised in any way.

    I moved one end of the cable so that one board was using slot 0, the other board slot 1. The software on each board was modified to use the appropriate slot.

    With slot 0 as the RC, there was still no data transfer.

    With slot 1 as the RC, the EP did manage to receive the data, but it looked like the software crashed before it was able to echo the data back to the RC.

    Do I have a software bug causing the crash?

    Thanks,

    Simon

  • Hi Simon,

    Ok, understood. If both ends are J721Es, then this scenario is exactly the one described here (documentation is pretty much the same between J784S4 and J721E): https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_01_02/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html

    To cross out the possibility of this being an issue with the hardware configuration, could you try running the Linux SDK example for PCIe EP in the above link? If our Linux example runs fine, then I think the possibility of the issue being related to hardware configuration will go down. I think a common issue is the cable, and how CLK and PERST needs to be disconnected for this cable - this is due to the EVM boards both having their own REFCLK and sending PERST will initiate a PORz on the EP side. For your experiments, I have suspicion that this behavior is caused by multiple clocks being sent due to the cable sending clocks from both RC and EP side.

    I think this experiment will narrow down where the issue could be, because if the Linux SDK does not run, then there is a higher possibility of an issue with hardware. And it would be easier on our side to replicate the experiment and debug any issues.

    Regards,

    Takuma