From: James Black <jblack547@gmail.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: mpc8270 and fs_enet
Date: Thu, 19 Feb 2009 09:18:28 -0700 [thread overview]
Message-ID: <b77025b40902190818l57c81b25xa8c94ca10528f0ad@mail.gmail.com> (raw)
In-Reply-To: <b77025b40901291527j74705c10y322e8bd8a0828600@mail.gmail.com>
Turns out the problem was with the PSDMR register. We had a cas
latency of 3 and the memory stick required 2. Also, the MPTPR register
had a value of 0x1e00 and we changed it to 0x1f00. We use ECC memory
sticks.
Those 2 changes got rid of the error in the buffer descriptor
ready/empty bits. The interesting thing was that our SDRAM memory test
passes and there are no errors logged in the TESCR1, TESCR2 or the
SDSR registers.
Strange problem, and difficult to find. Thought I'd get this out for
future reference.
On Thu, Jan 29, 2009 at 4:27 PM, James Black <jblack547@gmail.com> wrote:
> I thought the same thing. So I verified the memory map. We did have a
> conflict with the SPI stomping the FCC temp so we moved that. An
> interesting note is that we drop packets from time to time on the MCC
> as well due to a similar ready bit problem. The CPM never clears the
> bit.
>
> ------------------------------------------------------------------
> IMMR memory map
> ------------------------------------------------------------------
>> FCC1 Parameters 0x8400 256
>> FCC1 Temp buffer 0x9000 128
>> SCC1 Parameters 0x8000 256
>> SCC2 Parameters 0x8100 256
>> SCC4 Parameters 0x8300 256
>> SMC1 Parameters 0x0000 64
>> SMC2 Parameters 0x0040 64
>> SCC1 Buff Desc 0x0080 64
>> SCC2 Buff Desc 0x00C0 64
>> SCC4 Buff Desc 0x0100 64
>> SPI Param Pointer 0x89FC 2
>> SPI Parameters 0x9000 76
>> MCC2 Global Param 0x8800 128
>> MCC2 HDLC Param 0x2000 8192
>> MCC2 Extra Param 0xB000 1024
>
>
>
> On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood <scottwood@freescale.com> wrote:
>> James Black wrote:
>>>
>>> I've got an mpc8270 running the fs_enet v1.0 driver and we are having
>>> problems with randomly corrupted tx buffer descriptor ready bits. The
>>> CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same
>>> kernel with the 8260_io driver (kernel is from the denx ELDK4.2)
>>> running on the mpc8250 that works perfect.
>>
>> Is it possible that some other CPM block is configured to use the same DPRAM
>> area that the descriptors are in?
>>
>> -Scott
>>
>
>
>
> --
> Jim Black
> Senior Software Engineer
> Aztek Networks, Inc.
> 2477 55th Street, Suite 202
> Boulder, CO 80301
> www.azteknetworks.com
>
--
Jim Black
Senior Software Engineer
Aztek Networks, Inc.
2477 55th Street, Suite 202
Boulder, CO 80301
www.azteknetworks.com
prev parent reply other threads:[~2009-02-19 16:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 22:41 mpc8270 and fs_enet James Black
2009-01-29 23:05 ` Scott Wood
2009-01-29 23:27 ` James Black
2009-02-19 16:18 ` James Black [this message]
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=b77025b40902190818l57c81b25xa8c94ca10528f0ad@mail.gmail.com \
--to=jblack547@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).