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