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: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > bs.org] On Behalf Of KRONSTORFER Horst > Sent: Mittwoch, 25. Oktober 2006 14:48 > To: Andy Fleming; Dan Malek > Cc: [email protected] > 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:[EMAIL PROTECTED] > > Sent: Dienstag, 24. Oktober 2006 20:15 > > To: KRONSTORFER Horst > > Cc: [email protected] > > 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 > > > [email protected] > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > > > _______________________________________________ > Linuxppc-embedded mailing list > [email protected] > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
