trouble with FEC on MPC860T - FEC_INTERRUPT not going off?

[Wolfgang Denk]

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