FCC1 failing on large packet PINGS, while FCC2 is successful
embedded
embedded at akb.net
Wed Oct 1 02:46:05 EST 2008
Actually, it may have been a simple fix. Looking at the clocks. We
noticed something a little awry; Just rechecking the RM and the code
we found that within ep8248.c, the clock setup code had the RX and TX
clocks flipped.
FCC1 RX CLK should be Clock 10
FCC1 TX CLK should be Clock 11
in: arch/powerpc/platforms/82xx/ep8248.c
static void __init init_ioports(void)
- cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_RX);
- cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK11, CPM_CLK_TX);
-Alan
On Mon, Sep 29, 2008 at 8:43 AM, Scott Wood <scottwood at freescale.com> wrote:
> embedded wrote:
>>
>> We've found a way to get ping to fail all of the time by increasing
>> the size of the ping messages. When we use the max in Windows of
>> 65500, every ping to the first FCC1 Ethernet is dropped. However,
>> when we ping with a size of 65500 to the second FCC2 Ethernet
>> everything is fine and all echos are successful.
>>
>> In windows:
>> ping -l 64000 172.24.100.11 -t
>>
>> It definitely seems to be a problem with the mpc, but I'm not sure
>> where to look. Board? KErnel? boot loader? The two Ethernet devices
>> should be configured identically, and looking through the kernel code,
>> it seems that there aren't any preferred treatment differences. Could
>> the problem be in the bit-banging mdio control, or should I look
>> within fs_enet? We've got this reproducing on all of our boards and
>> it could also reside in the board setup...
>>
>> Does anyone with experience on the ep8248 and/or mpc8272 family,
>> fs_enet-* code have any ideas where I should look next?
>
> It looks very similar to what I was seeing on ep8248 -- the first ethernet
> port would fail when attempting to receive back-to-back packets. I didn't
> look into it too closely since I thought it was probably a board issue (I
> had only one, and the firmware never generated any traffic that resulted in
> back-to-back receives).
>
> I'd be very interested if you ever figure out what's wrong.
>
> -Scott
>
More information about the Linuxppc-embedded
mailing list