From: "Mark Chambers" <markc@mail•com>
To: "Stefan Nickl" <Stefan.Nickl@kontron•com>
Cc: linuxppc-embedded@ozlabs•org
Subject: Re: All-ones problem with FCC1 on MPC8541
Date: Fri, 29 Oct 2004 09:29:30 -0400 [thread overview]
Message-ID: <002c01c4bdbb$57c5eea0$0301a8c0@chuck2> (raw)
In-Reply-To: 1099054203.10741.13.camel@lucy.pep-kaufbeuren.de
> 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
next prev parent reply other threads:[~2004-10-29 13:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-28 17:20 All-ones problem with FCC1 on MPC8541 Stefan Nickl
2004-10-28 18:02 ` Mark Chambers
2004-10-29 12:50 ` Stefan Nickl
2004-10-29 13:29 ` Mark Chambers [this message]
2004-10-29 14:22 ` Kumar Gala
2004-10-29 14:47 ` Stefan Nickl
2004-11-18 10:13 ` Stefan Nickl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002c01c4bdbb$57c5eea0$0301a8c0@chuck2' \
--to=markc@mail$(echo .)com \
--cc=Stefan.Nickl@kontron$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox