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.

  • TI Thinks Resolved

Linux/66AK2E05: K2E EVM unable to acees netcp pktdma from dsp core

Part Number: 66AK2E05

Tool/software: Linux

We performed set of experiment to understand pktdma of netcp behavior and its configuration.

1. We found the in case of K2H  , no boot mode, hello words example is running fine which send the  "hello word " to some other pc and receive back by running the window application which send back what it received.

   We found here that  netcp packet dma RX and TX channel are able to enabled by cppi module.

2. Same is the case of when running linux in arm , BUT here on loading hello world application in dsp, ethernet link is accessible only from dsp.


Now in case of K2E.

1a, Same hello world application loaded  in dsp when  EVM is configured in no boot mode, here  We found here that  netcp packet dma RX and TX channel are  always  found in disable state .
  This behavior  is not understandable .

  Please let us know how  NETCP'S  pkt dma rx and tx  channel always get disable , even on forcefully trying to enable it in no boot mode??
  Something missing??

  • In reply to lding:

    Hello,

    Currently we are using pdk package and drivers of Qmms and Cppi from---  C:\ti\pdk_keystone2_3_01_04_07\packages\ti\drv  and running the example from C:\ti\mcsdk_bios_3_01_04_07\examples\ndk\helloWorld.

    Can you please conduct the test for above  mentioned package and drivers with the example code.

    Regards


    Anshul

  • In reply to lding:

    Hello

    We conducted a test with the binary provided by you NIMU_emacExample_EVMK2EC66BiosExampleProject.out on our K2E setup and following is the result. Please give a look at NETCP_PKTDMA_TX and NETCP_PKTDMA_RX memory region and mapping.

    Regards

    Anshul 

  • In reply to anshul rathi:

    Hi,

    The ETCP_PKTDMA_TX and NETCP_PKTDMA_RX memory region and mapping looked OK. Do you mean the code stuck at CSL_SerdesLaneEnable_Lane_Init_RX function?

    Regards, Eric
  • In reply to lding:

    Hi,

     The memory region of NETCP_PKTDMA_TX and NETCP_PKTDMA_RX is fine but the values off all the parameters in both TX and RX are 0 ( tx_enable is disable and same in case of rx)  and also want to know about Why is " the code stuck at CSL_SerdesLaneEnable_Lane_Init_RX function ? "

    Regards

    Anshul

  • In reply to anshul rathi:

    Hi,

    I can't reproduce your issue. I looked at the registers at my working K2E EVM, it didn't stuck at CSL Serdes calls, also ETCP_PKTDMA_TX and NETCP_PKTDMA_RX are 0. Do you have Ethernet cable connected to port 0 when you do the test?

    Regards, Eric
  • In reply to lding:

    Also, you used MCSDK 3.1.4.7, it is obsolete already. Please use the latest Processor SDK RTOS 4.3 on K2E, I recall that MCSDK has some serdes issue.

    Regards, Eric
  • In reply to lding:

    Hello

    Can you give us the download path for pdk_k2hk_4_0_3.

    Thanks

  • In reply to anshul rathi:

    Hi,

    I thought you use K2E, the latest 4.3 release can be download from: software-dl.ti.com/.../index_FDS.html
    If you want to try K2H as well: software-dl.ti.com/.../index_FDS.html

    Regards, Eric
  • In reply to lding:

    Hi,

    While running the " NIMU_emacExample_EVMK2EC66BiosExampleProject " with the latest 4.3 release for K2E, the code gets struct on " CSL_SerdesWaitForSigDet ". Can you explain why is it so? 

     Regards

    Anshul

  • In reply to anshul rathi:

    Hi,

    We don't have such issue when run the test as it is. If it is stuck, it meant it didn't detect signal from the remote side from the serdes level. Check if you have the Ethernet cable connected to the first Ethernet port of EVM.

    Regards, Eric

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.