• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 101 subscribers
  • Views 578 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

No packets sent when packet buffers in internal memory, DM648, NDK2.0

James Gort
Intellectual 590 points

Hi All-

I am trying to optimize the NDK2.0 running on a DM648 for fast UDP reception. Per the NDK documentation, one of the low-hanging fruit to do this is move the packet buffers from their default (SDRAM) to internal memory (L2 SRAM). When I do this, the part refuses to send any packets (e.g., no DHCP request packet seen via wireshark on host).

I have chased this down as much as I can--whether packet buffers in internal or external memory, everything looks good into emacEnqueueTx(EMAC_DescCh *pdc) function in CSL_EMAC.c, with the one difference that, as expected, the packet buffer location is either in external memory or internal memory. At the end of this function, after descriptor is set up, there is a call to "turn on the transmitter" -- it the case of packet in external memory, this is when the packet gets sent, and received by PC. When in internal memory, nothing happens.

To switch between the two, I simply re-locate .far:NDK_PACKETMEM to IRAM, and comment out the below lines in ethdriver.c:

//#define     EXTERNAL_MEMORY             1

//#define     EXTMEM                      0x80000000

This seemes to do the trick, but it seems the DMA in the 3PSW does not work when source of packet buffer is internal memory. Is there some other setting in the 3PSW I need to change, to tell the DMA which memory bank it will be doing DMA to/from?

Also, in trying to get to bottom of this, there is something I am very confused about--in CSL_EMAC.C, for example:

            pRegAddr = &CPSW3G_REGS->TX_HDP[0];
            *(pRegAddr + pdc->chInfo->chNum) = CPU_TO_HWBD(((Uint32)pDescOrg));

Is used to set the CPDMA transmit descriptor, which results in the DMA of the packet (at least in the case of packet in external memory). The location of the packet (pDescOrg) seems to agree with where the packet descriptor actually is on the DM648, so why to wee need to CPU_TO_HWBD, which subtracts 0x7E000 from this location?

Any help on this, or other tips to speed up UDP packet reception on the DM648, is greatly appreciated!

Best,

Jim

 

  • 0
    TI__Mastermind 32475 points

    Jim,

    I think you need to figure out who wrote the 3PSW and ask them because we don't have insight into that piece of software.  I don't think there's anything about the architecture that prevents using L2 memory with DMA.

    I don't know the specifics of the CSL_EMAC but subtracting an offset of 0x7E000 doesn't sound correct to me.  If this is working, when placed in external memory there must be a miscalculation there somewhere.

    Judah

  • 0 in reply to judahvang
    Intellectual 590 points

    Hi Judah-

    By "3PSW" I mean the 3-port switch that is in the DM648 silicon. My understanding of how it works is that a discriptor of the packet size and location is written to the CPPI Ram (also internal to DM648), and then the location in CPPI Ram of the packet to send is written to CPDMA_STATERAM TX Channel (0) Head Descriptor Pointer, which tells the 3-port switch to read the info from the CPPI Ram and DMA the packet to the EMAC. It is the "DMA the packet to EMAC" that seems not to be happening when the packet buffer location, which is part of the info about the packet stored in the CPPI Ram, is in internal memory rather than external.

    Hence, I don't know what you mean by "wrote the 3PSW" unless you mean the verilog.... is it a core that is purchased by TI from a 3rd party?

    Best,

    Jim

  • 0 in reply to James Gort
    TI__Mastermind 20805 points

    Hi Jim --

    I think Judah thought you meant "3rd party software" when you said 3PSW.   To us, 3rd party software means software from one of our partners or another vendor.   Sorry for the confusion.  I'll try and redirect this to someone in the device group that might no more about that switch and DMA and if there are any restrictions w.r.t. memory.

    -Karl-

  • 0 in reply to Karl Wechsler
    Intellectual 590 points

    Hi All--

    Just reposting in hopes of this getting attention. Is this the correct forum?

    I am doing project where DM648 acquires video from GigE Vision camera, and the project is a no-go if I can't somehow optimize the NDK from TI to enable faster reception of UDP packets. It seems moving as much as possible, especially the packet buffers, to internal memory (from their default in external) is quick way to make significant improvement. However, the DM648 3-port switch seems not to be performing as advertised when packets (I've only tested TX packets thus far--it fails during DHCP) are in internal memory. Can someone at TI reproduce this?

    Best Regards,

    Jim Gort

  • 0 in reply to James Gort
    TI__Mastermind 18320 points

    Jim,

    The switch hardware is something that is never handled in the NDK software.  I have moved this thread to the DM64x forum in hopes that it can get a faster response there.

    Dave

  • 0 in reply to David Friedland
    TI__Intellectual 1635 points

    I am assuming that you were following the instructions from this link:

    http://processors.wiki.ti.com/index.php/Network_Developers_Kit_FAQ#Q:_I_wonder_if_I_could_extract_some_additional_performance_from_NDK._Are_there_any_tips_to_make_sure_my_system_is_performing_at_top_notch.3F

     

    Can you make sure that L2 cache is disabled?

     

    Benoit

    P.S. If this response helps answer your question please mark this post as verified - Thanks
  • 0 in reply to Benoit Parrot
    Intellectual 590 points

    Hi Benoit-

    Yes, I have read the FAQ, though it seems off-line today.

    Currently, I have L2 set up as part cache, part SRAM, with the packet buffers in L2 SRAM. I will try making all of it SRAM, to see if that helps.

    Jim

  • 0 in reply to James Gort
    Intellectual 590 points

    With all of L2 set as SRAM, same problem. Just to make sure cache is not an issue, added a call to BCACHE_wbInvAll() in the case of internal memory, in all places in ethdriver.c was calling OEM_CacheClean() in the case of packet buffers in external memory (when I move to internal memory, I comment out the #define EXTERNAL_MEMORY). Again, the best I can tell is that the 3-port switch hardware is either refusing to DMA the packet to the EMAC when it is in L2, or it is DMA'ing from the wrong place--Everything looks the same in the two cases (packet content the same), with only difference being that packet address is 0xAxxxxx (L2) instead of 0xExxxxxxx (external SDRAM) when the packet info is written to the 3-port switch, and the DMA to EMAC is supposed to happen. In case of external SDRAM, the magic happens, in the case of L2, it does not (no packet sent).

    Can someone try to reproduce in the DM648? I am using "helloWorld" test app--just modify the cmd to put packet buffers in L2--e.g.,

    SECTIONS {
       .far:NDK_MMBUFFER {} > IRAM
       .JRG_MEM {} > IRAM
       .far:NDK_PACKETMEM {} > IRAM
    }

    and modify ethdriver.c to comment out #define EXTERNAL_MEMORY 1.

    In DM648, you will see DHCP fail, because the DHCP "request" is never sent by the DM648, due to 3-port switch issue.

    Thanks for any help on this!!!

    Jim