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