MPC5200 ethernet communication stops unexpected

[John Rigby]

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 <Hans.Thielemans at metris.com> 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 at 246tNt.com]
> Sent: woensdag 16 mei 2007 8:57
> To: David Kanceruk
> Cc: Hans Thielemans; linuxppc-embedded at 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 at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070516/19d4fad5/attachment.htm