MPC5200 ethernet communication stops unexpected

[Hans Thielemans]

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:david.kanceruk at gmail.com] 
Sent: dinsdag 15 mei 2007 17:04
To: Hans Thielemans
Cc: linuxppc-embedded at 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 <hans.thielemans at metris.com> 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
______________________________________________________________________