From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by ozlabs.org (Postfix) with ESMTP id 9D3422BF0A for ; Fri, 29 Oct 2004 23:27:25 +1000 (EST) Message-ID: <002c01c4bdbb$57c5eea0$0301a8c0@chuck2> From: "Mark Chambers" To: "Stefan Nickl" References: <1098984003.11434.12.camel@lucy.pep-kaufbeuren.de> <006301c4bd18$59cfc570$0301a8c0@chuck2> <1099054203.10741.13.camel@lucy.pep-kaufbeuren.de> Date: Fri, 29 Oct 2004 09:29:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: linuxppc-embedded@ozlabs.org Subject: Re: All-ones problem with FCC1 on MPC8541 List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > On Thu, 2004-10-28 at 14:02 -0400, Mark Chambers wrote: > > > The packet sizes I receive look reasonable, but the buffers are > > > filled only with 0xff. The same goes for sending, the contents > > > of the buffers are OK (dhcp discover...), but when capturing > > > the output on the other side with ethereal, the packet is again > > > all 0xff. > > > > > > We just discovered that apparently preamble, frame delimiter and FCS go > > > out over the MII (at least TxD[0:3] change state), so I don't suspect a > > > hardware bug. > > > > > > > I would guess the problem is at the DMA level, that the FCC is > > reading/writing > > ffs to/from memory for some reason. The preamble and FCS come from the > > FCC itself, not memory, so that's why you see them. I'd guess some kind > > of mismatch with the kind of cycles generated by the FCC DMA and the > > memory controllers. > > I've tried loopback mode today, and it's the same story: > only 0xff on the receiving end. That would still be consistent with a memory access problem. > We looked hard at the manuals for anything that could cause the > kind of DMA problems you describe, but yet to no avail. > The chapter about SDMA seems to mainly describe some error status > registers, and they remain at their default value when running the FCC. > > We'll try to get hold of CDS eval board schematics to check more on the > hardware side, in the meantime, do you have an idea of which registers > to look at in particular? > Unfortunately, I don't know anything specific about the 8541 [so why the &^%* are you saying anything?] What I do know is that we had a similar problem back in the 68360 days. My memory of the exact solution is a bit vague, but I clearly remember the 'all-ffs' packets. So I hope this isn't a red herring. But what do we know - we know the FCC is correctly generating and receiving ethernet packets. There has to be a legitimate premable and FCS or ethereal wouldn't see the packets at all. And on receive you see a correct length packet, just bad data. So the question is, where is FCC getting data from and saving to? Is the 8541 cache-coherent like the 82xx family? Maybe try flushing/ invalidating cache to make sure program data is getting to/from physical memory? Maybe it's an MMU translation problem - code and the FCC are not really accessing the same physical addresses? Perhaps you can try manually disabling cache and/or MMU, or trying to send a packet from ROM (I know it would be garbage, but if it's not FF you know you're on to something). This is all assuming you are using a debugger and can break into the driver and play with things... Mark Chambers