> I don't mean to offend you, but unless you have a custom-designed board, > I'd first check the code that handles the DMA copy mecahnism before > checking the hardware ;-)
No worries there. I'm no expert on most of this stuff. The DMA function is part of the PowerPC (8349) itself and I simply set up the start, end, length, that it's memory to memory transfer, and say "go". But there is a warning the manual I admit was fuzzy about cache coherency. I do have snoop enabled on the TSEC DMA controller. Maybe I'm just doing the unexpected with dma-ing out of TSEC memory. > Depending of the cache-line size, you might have to take care your pbufs > are aligned accordingly (if cache lines are 16 bytes, pbufs must start > at a multiple of 16 bytes and the length also must be a multiple of 16 > bytes!). Receive Buffer Descriptors are 64 byte aligned (I allocate 128 more than my MTU and adjust payload up to a 64 byte boundary). I've run with an LWIP_ASSERT on (payload % 64) == 0 to be sure it's not ever bad. This aligned payload address is stored in the BD. > Without that, you risk data corruption when you invalidate too > much (or too little) memory before copying or sending. Yes. I don't know where the cache fits in, but my hunch is the cache for memory used by the TSEC what is grabbed by a dma_memcpy has a small window for a hardware deadlock since the PPC goes unresponsive. I could set a watch dog I suppose but that won't resolve the lockup. > What Jonathan meant is: there is no limitation in lwIP to limit the > number of segments on the ooseq queue. This is what made me think maybe I want to limit them if I would run out of pbufs. I can allocate many more pbufs - what got me into this is I had too few pbufs than I thought I needed for the system and was running out. I can add plenty for OOSEQ now that I know I should. Before yesterday I didn't know about OOSEQs. > It is only limited by the remote > host not sending more (unacknowledged) segments thatn the receive window > can take (configured via TCP_WND and sent to the remote host when > establishing the connection). If 65535 is too much for your target, you > probably should send TCP_WND to a smaller value: Keep in mind that (if > you use the socket or netconn API), you have to be prepared to store the > complete receive window in memory before the application thread > processes it! I'm using raw TCP (well, a small socket-like NO_SYS layer on top of it). The lockup was for a different reason. I found I was out of pbufs from OOSEQ and didn't know what they were and how many pbufs are reasonable to reserve for it. I think 40-50 will be plenty. Thanks for your reply, Bill _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
