BCM5421 PHY on TSEC on MPC8560

hello!

I am currently attempting to boot linux (kernel 2.6.11) on an
MPC8560-based board: I have successfully fixed U-Boot to work and am now
attempting to get the kernel up - I have managed to get as far as I can
without mounting the root fs, adding a few fixes on the way. I attempt
to mount root fs via NFS and this is where I've been stuck for a few
days (I used 2.6.10 before, I just ported my board-specific changes over
to 2.6.11, hence the "few days").

I have a BroadCom BCM5421 PHY attached to MPC8560 TSEC. I have added
support for its aux status register and its initialization (via another
phy_info entry) to gianfar_phy.c and configured the kernel with Gianfar
driver without NAPI support. It seems that the link is established OK
(at least the switch that the board is connected to suggests so) and the
gfar_transmit() gets called, signalling that the buffers are being sent.
however, no packets seem to be thrown on the wire (nothing ever gets to
the other side).

Ethernet works perfectly in U-Boot. I have also compared the code and it
seems - apart from the architectural differences between U-Boot and
Linux kernel - that U-Boot does roughly the same thing as the kernel
does.

If anyone has any idea or hint whatsoever about what I could look into,
I'd appreciate it very much. Thanks!

regards,
        jaKa

-- 

w3: http://fish.homeunix.org/people/jaka
email: jaka@activetools.si

On Thu, 2005-03-03 at 10:31 +0100, Jaka Mo=C4=8Dnik wrote:

I have a BroadCom BCM5421 PHY attached to MPC8560 TSEC. I have added
support for its aux status register and its initialization (via another
phy_info entry) to gianfar_phy.c and configured the kernel with Gianfar
driver without NAPI support. It seems that the link is established OK
(at least the switch that the board is connected to suggests so) and the
gfar_transmit() gets called, signalling that the buffers are being sent.
however, no packets seem to be thrown on the wire (nothing ever gets to
the other side).

never mind: the board does not support the "phy interrupt", so the
driver has to use timer to poll for link changes in order to call adjust
link. removing the unfortunate flag from device definition for my board
was all it took. now it's time to make it 1000BT aware;)

regards,
	jaKa

--=20

w3: http://fish.homeunix.org/people/jaka
email: jaka@activetools.si