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.

TDA4VM-Q1: pcie2-pcie3 resoure collsion

Part Number: TDA4VM-Q1
Other Parts Discussed in Thread: TDA4VH, TDA4VM

Q1: the log is above ,we find the TDA4VH pcie2-pcie3 resoure collsion ,plz How to fix the dts file ,Thx

Q2: The SDK 8.2.2 Can support 4 PCIE ,so far PCIE0 PCIE1 is normal ,PCIE2 PCIE3 is abnormal

Q3: We shoule support pcie0~pcie3 refclk out for the EP ,How to setup the dts or the reg ,Thx

  • Hello, 

    please see notes for each of your question:

    A1: your log file shows that your pcie2 and pcie3 are incorrectly using the PCIE1_DAT0 region at 0x18000000. I assume you modified the SDK default dts and assigned 0x18000000 addresses for PCIe2 and PCIe3. You can revert back to the default dts, but make the following changes:

    in k3-j721e-common-proc-board.dts:

    for PCIe2:

    //this is the default EVM setup, corresponding to the M.2 slot on the bottome of the EVM.
    
    &pcie2_rc {
    reset-gpios = <&exp2 20 GPIO_ACTIVE_HIGH>;
    phys = <&serdes2_pcie_link>;
    phy-names = "pcie-phy";
    num-lanes = <2>;
    };
    

    for PCIe3, you need to change SERDES2 mux from USB to PCIe, change SERDESs refclk, configure WIZ3 and SERDES3 then enable PCIe3:   

    &serdes_ln_ctrl {
    idle-states = <J721E_SERDES0_LANE0_PCIE0_LANE0>, <J721E_SERDES0_LANE1_QSGMII_LANE2>,
    ..
    <J721E_SERDES3_LANE0_PCIE3_LANE0>, <J721E_SERDES3_LANE1_PCIE3_LANE1>,
    ..
    };

    &wiz3_pll1_refclk {
    assigned-clocks = <&wiz3_pll1_refclk>;
    assigned-clock-parents = <&cmn_refclk1>;
    };

    &wiz3_refclk_dig {
    assigned-clocks = <&wiz3_refclk_dig>;
    assigned-clock-parents = <&cmn_refclk1>;
    };

    &serdes3 {
    assigned-clocks = <&serdes3 CDNS_SIERRA_PLL_CMNLC>;
    assigned-clock-parents = <&wiz3_pll1_refclk>;

    serdes3_pcie_link: phy@0 {
    reg = <0>;
    cdns,num-lanes = <2>;
    #phy-cells = <0>;
    cdns,phy-type = <PHY_TYPE_PCIE>;
    resets = <&serdes_wiz3 1>, <&serdes_wiz3 2>;
    };
    };

    &pcie3_rc {
    reset-gpios = //USER YOUR OWN RESET GPIO as on your board;
    phys = <&serdes3_pcie_link>;
    phy-names = "pcie-phy";
    num-lanes = <2>;
    };

    please use these as examples instead of actual patches, due to - 1). SERDES3 on the EVm is used for USB. Thus I can not test. 2). RESET signal or PCIe3 depends on your system. 

    Jian

  •  Continued ...

    A2. please see above answer in A1. 

    A3. please refer to:

    (11) [FAQ] TDA4VM: TDA4VM/DRA829V: routing PCIE reference clock externally - Processors forum - Processors - TI E2E support forums

    let me know how if there are further questions. 
    jian

  • the TDA4VH is same with TDA4VM setup the PCIE ref clk out ?

  • Hi, Jian,

    Customer is debugging with TDA4VH, and they need to use PCIe0, PCIe1, PCIe2 and PCIe3. The supports needed include:

    1. example DTS to enable all the four PCIe instances

    2. example DTS to enable ref clock output

    As only PCIe0 and PCIe1 are used on TDA4VH EVM, so the DTS in SDK only enable these two PCIe instances. I have suggested customer engineer to refer to TDA4VM as PCIe2 is used on its EVM, but customer engineer feedback that he failed in enabling PCIe2 on TDA4VH.

    Please help to give some suggestions and hints on implementing customer's requirements. Thanks.

  • Fan/Haitang, 

    I did not realize the thread is on TDA4VH as I only paid attention to the title of the thread. 

    After Fan called, I reviewed and TDA4VH SERDES mux scheme, and realized each port will be using two lanes of SERDES0/1. So lets review your hardware configuration and dts in the norming.

    The mechanism to enable external refclk is similar to TDA4VM. I will explain in the call on which registers to check. 

    regards

    Jian

  • Fan, Haitang, 

    Below are the register controls to route PCIe refclk for J7AHP PCIe0 and PCIe1:

    1. For PCIe0/SERDES1

         - enable PCIE_REFCLK0_P/N_OUT IO pads

             --   write CTRL_MMR_PCIE_REFCLK0_CLKSEL[PCIE_REFCLK0_CLKSEL_OUT_CLK_EN] = 0'b1

         - Select ACSPCIe buffer input mux 

             -- write CTRL_MMR_PCIE_REFCLK0_CLKSEL[CTRL_MMR_PCIE_REFCLK0_CLKSEL] = 2'b01. This will select MAIN_PLL2_HSDIV4_CLKOUT as the input to the mux. This will not require SERDES1_REF_OUT_CLK to be enabled as in below step. 

         - Enable output of refclk from WIZ/SERDES (Not needed)

           -- during the discussion, we mentioned this step is needed. I it seems with the extra mux option, we can directly route the MAIN_PLL2_HSDIV4_CLKOUT to drive EP devices. So no need to enable the SERDES1_REF_OUT_CLK or SERDES1_REF_DER_OUT_CLK. We will revisit this topic later, when your system goes to EM testing, if Spread Spectrum (SS) clock is needed. In that case, we will first attempt to enable SS on MAIN_PLL2. If there are other subsystems sharing PLL2 can not use SS clock, then we can enable SERDES1_REF_DER_OUT_CLK, which is a SS version of SERDES1_REF_OUT_CLK. 

    2. for PCIe1/SERDES0

        - we can actually route the same MAIN_PLL2_HSDIV4_CLKOUT out for PCIe1. I attached a snippet of the mux options driving the ACSPCIe differential buffers for your reference. As this information may not be in the early access TRM. 

       - register to enable the output is WIZ16B8M4CT3_PHY_PMA_CMN_REGISTERS_PHY_PMA_CMN_CTRL2__PHY_PMA_CMN_CTRL1[cmn_refclk_rcv_out_en] at offset +0xe000.  

    regards.

    Jian

  • On the parallel debug of enabling PCIe2 and PCIe3, please share your current dts file for review. you can either post it here or email. 

    regards

    Jian

  • Hi, Jian,

    The modified code to enable ref clk out has been sent through email. With the modification, expected clk can not be measured on the pins. Please help to review.

    Thanks.

  • Fan, 

    sorry for the long delays. I will ask Achal to review the dts and followup debugs. 

    Jian

  • Hi all,

    Unlocking thread. Issue is still open and many ongoing internal email threads. Our field team should be updating our latest status, but opening this channel as this issue is still actively being debugged.

    Regards,

    Takuma