* All-ones problem with FCC1 on MPC8541
@ 2004-10-28 17:20 Stefan Nickl
2004-10-28 18:02 ` Mark Chambers
2004-11-18 10:13 ` Stefan Nickl
0 siblings, 2 replies; 7+ messages in thread
From: Stefan Nickl @ 2004-10-28 17:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to port my version of linuxppc-2.4 from 8540 to 8541.
The point I'm stuck at right now is the FCC that replaces the FEC.
I checked port configuration and clock routing registers in
cpm2_io/fcc_enet.c again and again, but all I get in and out is ones.
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.
Any ideas?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
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-11-18 10:13 ` Stefan Nickl
1 sibling, 1 reply; 7+ messages in thread
From: Mark Chambers @ 2004-10-28 18:02 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
> I checked port configuration and clock routing registers in
> cpm2_io/fcc_enet.c again and again, but all I get in and out is ones.
>
> 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.
Mark Chambers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
2004-10-28 18:02 ` Mark Chambers
@ 2004-10-29 12:50 ` Stefan Nickl
2004-10-29 13:29 ` Mark Chambers
2004-10-29 14:22 ` Kumar Gala
0 siblings, 2 replies; 7+ messages in thread
From: Stefan Nickl @ 2004-10-29 12:50 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
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.
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?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
2004-10-29 12:50 ` Stefan Nickl
@ 2004-10-29 13:29 ` Mark Chambers
2004-10-29 14:22 ` Kumar Gala
1 sibling, 0 replies; 7+ messages in thread
From: Mark Chambers @ 2004-10-29 13:29 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
2004-10-29 12:50 ` Stefan Nickl
2004-10-29 13:29 ` Mark Chambers
@ 2004-10-29 14:22 ` Kumar Gala
2004-10-29 14:47 ` Stefan Nickl
1 sibling, 1 reply; 7+ messages in thread
From: Kumar Gala @ 2004-10-29 14:22 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
[snip]
> 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?
Did not realize you were using a CDS, but physical ethernet port on the
board do you believe the FCC is hooked up to? While, some of the
issues you are having in internal loopback seem to mean other problems,
I believe the FCCs are only available for ethernet over some additional
adapter add on cards.
- kumar
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
2004-10-29 14:22 ` Kumar Gala
@ 2004-10-29 14:47 ` Stefan Nickl
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Nickl @ 2004-10-29 14:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
On Fri, 2004-10-29 at 09:22 -0500, Kumar Gala wrote:
> [snip]
> > 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?
>
> Did not realize you were using a CDS, but physical ethernet port on the
> board do you believe the FCC is hooked up to? While, some of the
No, sorry you got me wrong on that.
I don't have access to a CDS, we have swapped processors on some of
our EB8540 (EEBrain) modules. The board supports 8540 and 8541 since
as our hardware guy tells me, the MII lines from the 8540's FEC are N/C
on the 8541 BGA balls, as are the 8541's FCC1 lines in respect to the
8540 BGA balls.
I just assume the 8541 works on the CDS ;-), so we might spot a
helpful difference to our board's schematics.
> issues you are having in internal loopback seem to mean other problems,
> I believe the FCCs are only available for ethernet over some additional
> adapter add on cards.
Can you please confirm the CDS setup you describe does actually work
with linuxppc-2.4 v2.4.27_linuxppc and U-Boot built from the public CVS?
Regards,
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541
2004-10-28 17:20 All-ones problem with FCC1 on MPC8541 Stefan Nickl
2004-10-28 18:02 ` Mark Chambers
@ 2004-11-18 10:13 ` Stefan Nickl
1 sibling, 0 replies; 7+ messages in thread
From: Stefan Nickl @ 2004-11-18 10:13 UTC (permalink / raw)
To: linuxppc-embedded
On Thu, 2004-10-28 at 19:20 +0200, Stefan Nickl 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.
To whom it may concern: We finally solved it!
>From what I can tell, it's a bug in both linuxppc-2.4 AND the manual.
It's all about the values of RIPTR and TIPTR in the FCC parameter RAM,
to work on the MPC8541/MPC8555 they must not assume the values that the
current public kernel sets them to, and what is suggested by the manual.
First the manual bug: "For best performance, it should be located in the
following address ranges: 0x3000-0x4000 or 0xB000-0xC000."
However, the "Internal Dual-Port Data RAM Memory Map" shows both of
these ranges as "Reserved" in the MPC8555 manual (different from the
MPC8560 manual). This is also not mentioned in the latest errata.
Next the linux bug: This is from cpm.h in the public kernel:
#ifdef CONFIG_8272
#define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x00009000)
#else
#define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
#endif
and this is from cpm.h in the metrowerks 8555 kernel:
#if (defined(CONFIG_8272) || defined(CONFIG_8555))
#define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x00009000)
#else
#define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
#endif
Note that little difference? :)
When the internal buffers are placed in the non-reserved region,
it just works.
Greetings,
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-11-18 10:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2004-10-29 14:22 ` Kumar Gala
2004-10-29 14:47 ` Stefan Nickl
2004-11-18 10:13 ` Stefan Nickl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox