On 06/14/2005 01:59 PM Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hi Jan, >> >> I have now a first version of the RTnet driver for MPC52xx FEC running, >> at least rtping works. Unfortunately, porting of that beast from Linux > > Great. Don't hesitate to check in.
When it's ready and a bit more tested, of course. >> 2.4 to RTnet was not straight-forward: >> >> - As the MPC52xx has only one ethernet port, driver development might >> be cubersome. This limitation might be overcome by mounting a PCI >> ethernet card (if a PCI connector is available). >> > > That's why I'm preferring initrd over nfs-root for such scenarios. ;) > >> - The Linux driver fec.c cannot be loaded as kernel module (symbols not >> exported, etc.). This requires a small kernel patch. >> > > Mmh, not that nice. Is this a problem limited to specific kernel > versions, or is it still required even for the latest 2.6 that runs with > the MPC? The problem exists with the 2.4 kernel. Till now, the MPC5200 is not supported by the offical 2.6 kernel. I'm afraid, that with 2.6 there will be a re-written driver for the fec.c :-(. >> - The driver requires PHY management (MDIO) to get ethernet working. >> > > That should be no problem. I had the same situation with the SMC91111, > but this caused not troubles because the management is only needed > during device setup. I see. It calls schedule_timeout() in the smc_open() function in the real-time context. It's similar in the fec driver. > >> Is there already a policy how to handle link setup and changes? I assume >> that the link is setup when the driver is loaded or the device opened >> and link changes during runtime are not handled at all. > > Yep, that's the policy. Pulling out the cable etc. is a fatal error and > should not cause RTnet to try any reconfiguration during runtime. There > is still the plan to let some kind of error manager handle such events > and report it to interested applications. The applications could then, > e.g., start some safe shutdown procedure if their operation heavily > depends on a working network link. But this is just a plan, we did not > find the time to fully specify and implement it. OK. >> Where should I put supporting files for the driver like the mentioned >> kernel patch or a README. In the drivers directory? >> > > Yes, this is also what I would suggest. We may also refer to that README > in the main README or in the configure script in case the user switches > that driver on. OK. Thanks. Wolfgang. > > Jan > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > RTnet-users mailing list > RTnet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
