This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: MPC860, instruction cache & ethernet
- To: Ross Wightman <rwightma at sfu dot ca>, ecos-discuss at sources dot redhat dot com
- Subject: Re: [ECOS] MPC860, instruction cache & ethernet
- From: "Lewin A.R.W. Edwards" <larwe at larwe dot com>
- Date: Fri, 08 Dec 2000 20:23:26 -0500
Hi Ross,
>Unfortunately it looks like we are having some speed problems. The ethernet
>driver works (a little), it can send out some packets, and receive some, but
>it doesn't seem to be able to keep up with the incoming packets very long as
>the buffers fill up and the network layer dies. Since we our bsp is based
>of the MBX code, both of the caches are off by default so our board is
I agree with the diagnosis that this is probably the major culprit in your
overrun problems!
This is probably very obvious advice, but:
>running slower than it should be. I have tried enabling the caches in the
>assembly startup but the network driver won't work at all when either of the
>caches are enabled. This is unfortunate because enabling these, especially
>the i-cache, improves the timings (tm_basic test) by a large margin.
I don't know this architecture, but when you enable icache you may also be
enabling pipelining that may be causing your problems. Or you may be
violating some setup timing parameter of the ethernet cell.
If it was my code, I would first put detailed traces through all the
ethernet initialization code to see exactly where it is failing. If no
other options present themselves, then put delay loops between each write
to the ethernet registers.
Once you know it is being inited OK, then put the device on a totally
isolated ethernet segment, attach one other device to generate some
traffic, and breakpoint the ISR for the ethernet interrupt. If you're
getting interrupts then you're halfway there.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/