Ethernet not initialized: Help req

[batsayan.das at tcs.com]

Hi,

We got the correct value of CLK9 and CLK10. We found out a bug in the 
function fcc_enet_open(). Our setting was CONFIG_USE_MDIO. In this mode, 
the board is able to get packets from out side, but was unable to send 
packets. 

Now we changed the code like this. 

                fep->link = 1;
                netif_start_queue(dev);
                mii_do_cmd(dev, phy_cmd_config);  /* display configuration 
*/
                return 0; 

Originally the code was ( Line no 2174)

                netif_start_queue(dev);
                return 0;               /* Success */

Now the ethernet works perfectly. 

BTW, is there any tool/test case available to test the ethernet driver for 
a long period of time? 

Thanks
Batsayan Das




Wolfgang Denk <wd at denx.de> 
Sent by: wd at denx.de
01/12/2006 02:04 AM

To
batsayan.das at tcs.com
cc
Linuxppc-embedded at ozlabs.org
Subject
Re: Ethernet not initialized: Help req






In message 
<OFDC66830E.1EDE14C4-ON652570F3.00265CDF-652570F3.00297A66 at tcs.com> you 
wrote:
> 
> In our MPC8260 based customs board the CLK9 is for transmit and CLK10 is 

> for receive. The ELDK tree uses  CLK12 is receive, CLK11 is transmit and 


This is not correct. The ELDK does not do this. The  ELDK  is  not  a
Linux source tree.

Also, this setting is hardware dependent and differs  from  board  to
board.

> We got CLK9  and CLK10 from U-Boot tree and set those varables, but 
> ethernet does not work. 

Then   probably   other   changes   /   initializations   (port   pin
configurations) are needed as well.

> My question is what value shall I use for CLK9 and CLK10? 

This idepends on your hardware. Study the schematics.

> What else setting we need to change to make Ethernet work?

Compare U-Boot code and other board definitions.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A secure program has to be robust: it  must  be  able  to  deal  with
conditions  that "can't happen", whether user input, program error or
library/etc. This is basic damage  control.  Buffer  overflow  errors
have nothing to do with security, but everything with stupidity.
                 -- Wietse Venema in <5cnqm3$8r9 at spike.porcupine.org>

ForwardSourceID:NT00008EB6 


Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information.   If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited.   If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments.  Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060112/a8a355f2/attachment.htm