MPC834x TSECs/Gianfar w/o MDIO accessible PHYs

[KRONSTORFER Horst]

andy, dan, thanks for your replies! 

> Look at the driver in drivers/net/phy/fixed.c.

i did that w/o luck. the results are 100% the same compared to the
'remove phy/mdio support' approach. i therefore assume that the source
of the problem must be something else.

debugging around gfar_start_xmit() i made the following observations:

1) dumping skb->data i see correct frame data.

2) dumping txbdp->bufPtr (using a bdi) i sometimes see correct frame data,
sometimes the corrupted frame data as i see it on the wire.

3) regardless of 2) the data of these frames is always corrupted on the 
wire.

on the 1st look this seems to be some kind of caching effect, but then ...

thanks
-h

> -----Original Message-----
> From: Andy Fleming [mailto:afleming at freescale.com] 
> Sent: Dienstag, 24. Oktober 2006 20:15
> To: KRONSTORFER Horst
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
> 
> Look at the driver in drivers/net/phy/fixed.c.  It probably 
> needs some documentation, and Vitaly implied it needed a 
> little tweaking, but it provides the basics of what you need 
> (and what Dan mentioned).  Essentially, you need to fake the 
> PHY.  However, if you wanted, you could also get smarter and 
> write a new mdiobus driver, which handles configuring and 
> using the switch.
> 
> I'm not quite sure why your approach isn't working, but I 
> agree with Dan's suspicions that removing the PHY code 
> doesn't just work.
> 
> One thing to check is the adjust_link() function.  You need 
> to make sure that you have the carrier on, and that the MAC 
> is set to MII mode, rather than GMII mode.
> 
> Andy
> 
> On Oct 24, 2006, at 04:16, KRONSTORFER Horst wrote:
> 
> > hi!
> >
> > in our design we use an mpc8343 with the 2 tsecs connected to a 
> > zarlink zl50411 eth switch in mii mode. the 2 ports of the 
> switch are 
> > running in phy mode (reverse mii) w/o mdio. we're currently running 
> > kernel 2.6.17.13.
> >
> > i therefore 'simply' removed the mdio bus and phy support 
> and tested 
> > with ping over tsec0. result: i can see arp requests which 
> are some- 
> > what malformed (dest mac addr is not bcast, source ip addr is 
> > incorrect, etc ...) btw: i used the same approach in u-boot and it 
> > works fine.
> >
> > i then checked the content of the sk_buff handed over to 
> > gfar_start_xmit which is correct (mac addrs, ip addrs, ...)
> >
> > i'm currently out of ideas, any kind of help is appreciated!
> >
> > thanks
> > -h
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
>