2008-04-23 17:14:50     Debugging ethernet (hardware) problem

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2008-04-23 17:14:50     Debugging ethernet (hardware) problem

Graeme Smecher (CANADA)

Message: 54805    Hi,

 

I've just brushed the dust off my bf533-stamp board, only to find out the Ethernet doesn't work. With a loopback cable into a generic 10/100 PCI card, I *can* do the following:

 

   * ping other hosts from u-boot

   * successfully tftp a kernel and disk image

 

As soon as I get into uClinux (2008R1-rc8, both the release image and one compiled here), I can't seem to get any more life out of it. I've done everything I can think of (changing cables, inserting a 10-mbit switch, et cetera), but it seems like the Ethernet hardware is fried in a way that doesn't bother u-boot, but bothers Linux. U-boot seems to like whatever combination I throw at it, and linux always considers the link down.

 

For what it's worth, I gave up on the board shortly after feeding it an 18V DC input. It's within ratings (7.5-20v), but the result cooked (at very least) my USB-serial adapter. Thus the reason the board was gathering dust in the first place. I've also noticed the lan91c111 gets quite physically hot, but I can't recall whether that's normal or not.

 

Any suggestions? I'm especially curious to know what the smc91x driver *should* produce when SMC_DEBUG is 2 or 3, to help me figure out what my hardware isn't doing correctly.

 

thanks,

Graeme

bootlog

QuoteReplyEditDelete

 

 

2008-04-23 17:42:59     Re: Debugging ethernet (hardware) problem

Robin Getz (UNITED STATES)

Message: 54808    Graeme:

 

When the network works in U-Boot, and not in linux - that normally means an interrupt is not set up properly.

 

this can either be a physical problem (HW issue) or a logical one (software).

 

What does 'proc/interrupts' show?

 

-Robin

QuoteReplyEditDelete

 

 

2008-04-24 08:16:29     Re: Debugging ethernet (hardware) problem

Graeme Smecher (CANADA)

Message: 54853    Hi Robin,

 

noreply@blackfin.uclinux.org wrote:

> Graeme:

>

> When the network works in U-Boot, and not in linux - that normally means an interrupt is not set up properly.

>

> this can either be a physical problem (HW issue) or a logical one (software).

>

> What does 'proc/interrupts' show?

>  

 

    root:/> cat /proc/interrupts

      6:       2260   BFIN Timer Tick

     21:          0   BFIN_UART_RX

     22:        730   BFIN_UART_TX

     40:          0   eth0

    Err:          0

    root:/> ifconfig

    eth0: smc_query_statistics

    eth0      Link encap:Ethernet  HWaddr 00:E0:22:FE:06:AF              inet addr:192.168.128.99  Bcast:192.168.128.255    Mask:255.255.255.0

              UP BROADCAST MULTICAST  MTU:1500  Metric:1

              RX packets:0 errors:0 dropped:0 overruns:0 frame:0

              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

                        Interrupt:40 Base address:0x300 DMA chan:ff

 

    lo        Link encap:Local Loopback              inet addr:127.0.0.1  Mask:255.0.0.0

              UP LOOPBACK RUNNING  MTU:16436  Metric:1

              RX packets:0 errors:0 dropped:0 overruns:0 frame:0

              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:0

    root:/>

 

 

 

Good instincts... it looks like lan91c111 interrupts aren't making it to the Blackfin.

 

I've just had a look at the LAN_IRQ pin on the CPLD -- it goes high and stays there for a while shortly after the kernel starts up. However, PF7 (which should be a straight-through connection) does nothing at all.

 

I'll track down a JTAG pod to reconfigure the CPLD, or perhaps just lift the offending CPLD pin. (I wonder what else I fried?)

 

thanks,

Graeme

QuoteReplyEditDelete

 

 

2008-04-25 10:12:45     Re: Debugging ethernet (hardware) problem

Graeme Smecher (CANADA)

Message: 54958    FYI, I lifted the CPLD's LAN_IRQ and PF7 pins off the PCB and bridged the pads by hand. The Ethernet now works like a (slightly battered) champ. Thanks again for your help.

 

cheers,

Graeme

Attachments

Outcomes