trouble with FEC on MPC860T - FEC_INTERRUPT not going off?
Wolfgang Denk
wd at denx.de
Sat Dec 2 20:23:50 EST 2000
Dear Dan,
in message <20001201223622.A28837 at slug.rtp.ericsson.se> you wrote:
>
> I've ported ppcboot to a custom MPC860T-based board which uses the
> FEC, and am now working on the kernel. At the moment, I'm using the
> 2.4-2000-11-11 kernel from ftp.denx.de as a baseline, since it
> seemed to be a good starting point.
This version of the kernel is derived from 2.4.0-test5 from July, 26.
> I've created my own header file in include/asm-ppc/, with board info
> struct, IMMR, and defined FEC_INTERRUPT to be SIU_LEVEL1. I've
> corrected drivers/net/setup.c to call fec_enet_init. The kernel
> boots, and gets down to this point, where the FEC is detected, but
> the PHY is not, and so eth0 can't be opened:
That's exactly the behaviour I have seen myself.
> I've poked around, and it appears that the MII command queued at the
> end of fec_enet_init() is never processed. It appears that this
> processing should be done from fec_enet_mii(), which is called from
> the FEC interrupt routine, fec_enet_interrupt(). To prove the
> point, I placed a printk() at the beginning of fec_enet_interrupt().
> It never appeared on the console, so I conclude that FEC interrupts
> aren't happening.
If you look closer, you will see a very fundamental problem - I
wonder, if this code has ever worked for anybode (ummm, maybe older
mask revisions of the MPC860T worked differently?):
Some of the nitialization of the device is done in fec_enet_init(),
and the rest in fec_restart() [and there is a lot of redundancy
here]. But the only place where fec_restart() is ever called is the
MII interrupt handler, and for MII to work you must set the
FEC_ECNTRL_ETHER_EN bit in the fec_ecntrl register. Now guess where
this bit is set? Right, in fec_restart().
I have re-arranged all this stuff a bit, and added a configuration
option that allows to completely switch off all MII related code
(because I have some systems where it isn't needed because the PHY
uses hardware or auto-configuration).
> I'm aware that the MII can also have an interrupt assigned, though
> the current code makes it appear to be optional (only the FADS board
> seems to run request_8xxirq() on it). The PHY IRQ line (it's an
>From my understanding, the PHY interrupt is essential when you use MII.
> Level One LXT972LC) isn't hooked up to the 860, though it could be.
That's the same we used.
> Thinking this might be the problem, I put a scope on the LXT972's
> MDINT* pin, and rebooted the kernel. No interrupts at all. So,
> unless I'm missing an interaction, hooking that up would be unlikely
> to change the current problem.
Just for verification, you might try to add some debugging code in
the MII routines; as long as the FEC_ECNTRL_ETHER_EN bit isn;'t set
in the fec_ecntrl register, I always read 0xFFFFFFFF from the
fec_mii_data register.
> I imagine I'm missing something obvious, but I can't figure out what
> it would be right now. Has anyone got any suggestions, or perhaps
> has run into this type of problem before?
I have run into the same problem, and my suggestion is to try the
version of fec.c I'll attach below (I've sent this to Dan Malek some
days ago, but haven't heard anything since).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fec.c.bz2
Type: application/x-bzip2
Size: 12495 bytes
Desc: fec.c.bz2
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20001202/3e9362c6/attachment.bin
More information about the Linuxppc-embedded
mailing list