Hello Hans, There sure seems to be strange behavior in the BestComm unit. Our problem was always with the first byte or the 63rd byte on a buffer of 102 bytes.
Did you use a value of (1<<16) for the BSDIS bit? We also do a ioremap when setting a pointer to the xlb. Dave On 5/15/07, Hans Thielemans <[EMAIL PROTECTED]> wrote: > Hello David, > > In this case, I am flushing cache. And overall, these are empty packets > sent which are never changed. > The cpu creates this once and then this is always reused. It is received > maybe 100000 times correct and > then suddenly I see an error in the last word. > > I also tried playing with the BSDIS and PLDIS bits, and with the bus > priorities. This influences the error rate, > but it is never really gone. > > As a hack I have now added an extra word after the packet, and have the > receiver ignore it. This seems to help, > but I don't like it. > > Regards > > Hans > > -----Original Message----- > From: David Kanceruk [mailto:[EMAIL PROTECTED] > Sent: dinsdag 15 mei 2007 17:04 > To: Hans Thielemans > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: MPC5200 ethernet communication stops unexpected > > 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. > > Perhaps you are also experiencing a caching problem. > > Best regards, > > David Kanceruk > > On 5/15/07, Hans Thielemans <[EMAIL PROTECTED]> wrote: > > Hi David, > > > > I have a similar problem. I use the PSC for communication to a DSP. > > With the MPC5200 this has always worked. Now we got boards with the > > MCP5200B in place. > > > > The bestcomm dma seems to miss bits, bytes in the last word (32bit) of > > > a dma block. Mostly it is one byte which becomes 0. The blocks are 256 > > > bytes and written/read by 32 bits. > > The behavior is influenced by cpu activity, bus priorities. So far I > > found no settings which have never errors. > > > > Did you have any further progress? > > > > Regards > > > > Hans Thielemans > > > > > > -- > David Kanceruk > > "The generation of random numbers is far too important to be left to > chance." > > ______________________________________________________________________ > 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 > ______________________________________________________________________ > > > -- David Kanceruk "The generation of random numbers is far too important to be left to chance." _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded