MPC834x TSECs/Gianfar w/o MDIO accessible PHYs

[KRONSTORFER Horst]

hi!

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

setting CONFIG_NOT_COHERENT_CACHE=y fixed the problems. what baffles me is
that on my
mpc8349emds, which has afaik the same core (e300), CONFIG_NOT_COHERENT_CACHE
is _not_
defined and eth comm works fine.

any clues?

thanks
-h

> -----Original Message-----
> From: 
> linuxppc-embedded-bounces+hkronsto=frequentis.com at ozlabs.org 
> [mailto:linuxppc-embedded-bounces+hkronsto=frequentis.com at ozla
> bs.org] On Behalf Of KRONSTORFER Horst
> Sent: Mittwoch, 25. Oktober 2006 14:48
> To: Andy Fleming; Dan Malek
> Cc: linuxppc-embedded at ozlabs.org
> Subject: RE: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
> 
> 
> 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
> > 
> > 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>