Sylvain, This is a shot in the dark but the fact that it is the last word that is wrong reminds me of your question last week about the Gen_BD_TX tasks: > 2) From what I understand, this part process everything execpt the last > byte : > > 0xd9190300, /* LCDEXT: idx2 = idx2; idx2 > var12; idx2 += inc0 */ > 0xb8c5e009, /* LCD: idx3 = *(idx1 + var00000015); ; idx3 += inc1 */ > 0x03fec398, /* DRD1A: *idx0 = *idx3; FN=0 init=31 WS=3 RS=3 */ > > and this process the remaining (1 to 4) bytes : > > 0x9919826a, /* LCD: idx2 = idx2, idx3 = idx3; idx2 > var9; > idx2 += inc5, idx3 += inc2 */ > 0x0feac398, /* DRD1A: *idx0 = *idx3; FN=0 TFD INT init=31 > WS=1 RS=1 */ > > But the first group stops when the remaining length <= 4 (continue > while idx2 > var12, and var12 = 4). So if the buffer has a size multiple > of 4, that means the last 4 bytes will be processed 1 by 1. But that > means they may not be written as a full word access right ? I'm writing > to the AC97 fifo and from doing tests without DMA, not doing full 32 > bits write just doesn't work. As I said just a shot in the dark. John On 5/16/07, Hans Thielemans wrote: > Hello Sylvain and David > > I think it is a more basic problem then just cache. The setup is using > the psc2 and > psc3 in codec32 mode to communicate with a DSP. Because the MPC5200 had > problems with > the frame in slave mode (anomaly list), it is used in master mode, and > sends empty packets > of 256 bytes to keep the link active, so the DSP can send the data. This > because the send and > receive clocks and frames are the same on the mpc5200 side. > > The empty packet is a fixed packet in memory, so it is never overwritten > by the mpc5200 once > the driver is initialized. So I can not believe in a cache problem. The > problem is always in the > last 32 bit word or last 4 bytes in the package. The error rate seems to > be influenced by cpu activity > and bus priorities. > > I have now changed the protocol to send 260 bytes and just drop the last > 4 bytes at the receiver. > This way I had it running this night, transmitting 50 GB without a > single error. > > I would assume it has something to do with the bastcomm engine tasks at > the end of a dma block. > And probably something with the bus access. I tried several settings for > the arbiter and bus configurations > by changing the registers from within the bdi2000 debugger. Changing > behavior but no solution. > > In the full system there are 6 bestcomm tasks active: fec rx and tx, > psc2 rx and tx and psc3 rx and tx. > > Regards > > Hans > > > > -----Original Message----- > From: Sylvain Munaut [mailto:tnt@246tNt.com] > Sent: woensdag 16 mei 2007 8:57 > To: David Kanceruk > Cc: Hans Thielemans; linuxppc-embedded@ozlabs.org > Subject: Re: MPC5200 ethernet communication stops unexpected > > David Kanceruk wrote: > > Hello Hans, > > > > Our problem was with the FEC sending data with one or two > > incorrect bytes when we switched from the MPC5200 to the MPC5200B. The > > > byte positions were always the same. The socket buffer has the correct > > > data before and after the DMA engine runs but the FEC TxFIFO does not > > always match. > > > > One solution to our problem was to make the following call prior to > > starting the DMA: > > > > flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data > > + skb->len); > > > > The other solution was to set the BSDIS bit in the XLB config register > > > during initialization as follows: > > > > xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB; > > out_be32(&xlb->config, in_be32(&xlb->config) | > > MPC52xx_XLB_CFG_BSDIS); > > > > Either solution works for us. The BSDIS bit is a new feature in the > > MPC5200B. The MPC5200 did not have this bit. > > > > According to the Freescale documentation, (Application note AN3045, > > for instance) setting this bit is supposed to "disable" BestComm bus > > snooping. However, I have reason to believe the documentation is in > > error. Everything I have observed seems to indicate that in the > > MPC5200 BestComm bus snooping was always enabled or enabled via some > > other means. In the MPC5200B it appears to be "disabled" at reset (not > > > "enabled" as the documentation states). This is why flushing the cache > > > manually is one solution. Since setting the BSDIS bit also fixes the > > problem, it suggests that this actually "enables" BestComm bus > > snooping instead of disabling it. In my mind, it could all boil down > > to a simple documentation error. > > > That problem is _very_ weird ... > > From what I understand, Bestcomm XLB snooping means that when the > BestComm engine has some data cached internally and that it detects a > write to the address from where those data comes, he will invalidate his > cache. > > But when the kernel writes data to the skb buffer, they may partially > stay in cache so there won't be any transaction at all on the xlb bus. > It's when > bestcomm will read the skb, that the core will snoop the bus, detects > there is a read request for some data he has in cache, force a retry of > the bestcomm read, write the data to memory (via xlb), and finally let > bestcomm retry the transaction to fetch the good data. > > So I guess what "could" happen is that : > - The kernel allocate a skb, but it ends up being as the same memory > location > as a "previous" one. (or maybe in a directly following position > because of > prefetch). > - You submit it to bestcomm > - When bestcomm does the read, since the skb was used "just before", > the line is still in cache but with the wrong data. Since the kernel > just wrote the data, there was not yet a xlb transaction because the > data are still in cpu cache. > Bestcomm think he has the data (no xlb write so it's cache was not > invalidated), so he doesn't generate a xlb read. But if there is no xlb > read the core doesn't get a chance to snoop it and doesn't flush it's > cache ... > > Although that doesn't explain why setting BSDIS high solve the problem, > nor why there is only 1 byte wrong ... > > Have you checked your XLB snoop window setting ? And that core snooping > is enabled ? Also that you don't use the "nap" power saving feature of > the core ? (it disables snooping altogether ...). > > > Sylvain > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded >