On 1/12/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > Javi Roman wrote: > > On 1/12/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >> Javi Roman wrote: > >>> On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >>>> Javi Roman wrote: > >>>>> On 1/10/07, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote: > >>>>>> Jan Kiszka wrote: > >>>>>>> Javi Roman wrote: > >>>>>>>> ... > >>>>>>>> I think the driver requires PHY management (MDIO) to get my ethernet > >>>>>>>> working, and from the brand new rtnet-0.9.7 (rt_mpc8xx_fec.c): > >>>>>>>> > >>>>>>>> #ifdef CONFIG_RTAI_RTNET_USE_MDIO > >>>>>>>> #error "MDIO for PHY configuration is not yet supported!" > >>>>>>>> #endif > >>>>>>> OK, that's something Wolfgang has to comment on. > >>>>>> As the message says, MDIO is not supported. > >>>>>> > >>>>>>>> All MDIO stuff is under this macro. > >>>>>>>> I don't know why is not supported, nevertheless I'm going to work > >>>>>>>> with > >>>>>>>> this issue. > >>>>>>> The original phy management here includes timed jobs that you don't > >>>>>> want > >>>>>>> in a deterministic environment, therefore they have been switched off. > >>>>>>> Of course, this only makes sense when those jobs are not required to > >>>>>>> keep the link running. If they are needed to bring it up, a smart > >>>>>> way to > >>>>>>> only do this during fec_enet_open has to be found. > >>>>>>> > >>>>>>> The golden rule is: Keep "comfort" functions out of the critical path. > >>>>>>> If you have high rate deterministic traffic, some link watchdog at a > >>>>>> few > >>>>>>> HZ will choke far too late anyway. In this case, error detection can > >>>>>>> best be performed at higher levels. > >>>>>> Before we think more about PHY support some more questions: > >>>>>> > >>>>>> - did you disable the FEC driver in Linux via kernel config > >>>>> Yes I did. > >>>> OK. > >>>> > >>>>>> - do you see link up messages or are the corresponding LEDs on or > >>>>>> blinking. > >>>>> LEDs are on but they aren't blinking when I try something like > >>>>> "rtroute solicit ....". > >>>>> The driver output queue only is freed when the network wire is > >>>>> unplugged. Only raises the handler fec_enet_interrupt when the > >>>>> network wire is unplugged. > >>>>> > >>>>>> - does FEC work under Linux without PHY support (try disabling PHY > >>>>>> support via kenrel config). > >>>>> I'm trying this one right now. > >>>> OK, I'm going to check for old bugs now. Nevertheless, the software > >>>> versions of Linux, RTAI and RTnet are very old :-(. > >>>> > >>>> Wolfgang > >>>> > >>>> > >>>> > >>>> > >>> I'm sorry for ask this question again but any idea is good for me, I > >>> know that these software versions are ancients. > >>> > >>> I think that my board works without MDIO, so the following is with the > >>> original rtnet FEC driver (with MDIO unsupported). > >>> > >>> I have detected a problem with the flag FEC_ECNTRL_ETHER_EN, this flag > >>> is cleared (I don't know where) when the function > >>> fec_enet_start_xmit() tries to trigger the transmission start with > >>> fecp->fec_x_des_active = 0x01000000. The following are some traces of > >>> my execution: > >>> > >>> 1. Driver load: > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# insmod mpc8xx_fec-rt.o > >>> RTnet: registered rteth0 > >>> rteth0: FEC ENET Version 0.3, irq 7, addr 00:a0:26:23:57:2c > >>> rteth0: FEC with MDIO disable > >>> > >>> 2. Inteface open (with network wire connected): > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 > >>> fec_restart: restarting FEC, duplex = 1 > >>> fec_stop: stopping > >>> fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > >>> Full duplex > >>> fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN > >>> fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > >>> fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > >>> > >>> 3. Trying get the ARP response: > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev > >>> rteth0 > >>> fec_enet_start_xmit: data len is 42 > >>> fec_enet_start_xmit: Link is up > >>> fec_enet_start_xmit: setting X_DES_ACTIVE > >>> fec_enet_start_xmit: BD_ENET_TX_UN -> 0 > >>> fec_enet_start_xmit: FEC_ECNTRL_PINMUX -> 1 > >>> fec_enet_start_xmit: FEC_ECNTRL_ETHER_EN -> 0 > >>> fec_enet_start_xmit: transmission start triggered > >>> > >>> [From this point nothing more happends] > >>> > >>> 4. I close the NIC interface: > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 down > >>> fec_stop: stopping > >>> fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > >>> > >>> 5. Disconnect the network wire and set up the interface again: > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtifconfig rteth0 up 10.10.10.1 > >>> fec_restart: restarting FEC, duplex = 1 > >>> fec_stop: stopping > >>> fec_stop: FEC_ECNTRL_ETHER_EN -> 0 (already down) > >>> Full duplex > >>> fec_restart: setting FEC_ECNTRL_PINMUX | FEC_ECNTRL_ETHER_EN > >>> fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > >>> fec_enet_open: FEC_ECNTRL_ETHER_EN -> 1 > >>> > >>> 7. Now the FEC interruption is raised, because of the ETHER_EN flag is > >>> set correctly: > >>> [EMAIL PROTECTED]:/realtime/rtnet/sbin# ./rtroute solicit 10.10.10.2 dev > >>> rteth0 > >>> fec_enet_start_xmit: data len is 42 > >>> fec_enet_start_xmit: Link is up > >>> fec_enet_start_xmit: setting X_DES_ACTIVE > >>> fec_enet_start_xmit: BD_ENET_TX_UN -> 0 > >>> fec_enet_start_xmit: FEC_ECNTRL_PINMUX -> 1 > >>> fec_enet_start_xmit: FEC_ECNTRL_ETHER_EN -> 1 > >>> fec_enet_interrupt: in ISR > >>> fec_enet_tx: TX path > >>> TXI: c65ff100 c6937990 0 > >>> fec_enet_tx: dev_kfree_rtskb, sk buffer freed > >>> > >>> [One thing more, the fep->link value is not correctly handled] > >> At least you got an TX done interrupt telling the the packet has been > >> handle and sent out. Do you see the packet with a network sniffer? > >> > > > > No. The interrupt is only triggered when I set up the interface with > > the network wire unppluged, so I cannot sniff the packets from the PPC > > board. Just when I connect the network wire the flag > > FEC_ECNTRL_ETHER_EN is again cleared and the ISR is not triggered any > > more. > > > > If I force the flag in fec_enet_start_xmit(): > > ... > > fecp->fec_ecntrl |= FEC_ECNTRL_ETHER_EN; > > fecp->fec_x_des_active = 0x01000000; > > printk(KERN_CRIT "%s: transmission start triggered)\n", __FUNCTION__); > > ... > > > > the ISR is triggered and I can sniff packets (ARP and ICMP with rtping). > > Hm, strange. FEC_ECNTRL_ETHER_EN is set in fec_enet_init() via > fec_enet_restart(). > > > >>> Any thing more to prove? Any idea? > >> I'm trying to get RTnet 0.7.1 built and running on my TQM866M board. > > Attached is the log of performing rtping on my TQM860L module with Linux > 2.4.25, RTAI 2.4.13 and RTnet 0.7.1. The FEC-Ethernet is connected to my > local network via ethernet switch for testing purposes. I can also do a > "ping" to rteth0. > > I'm still puzzled what's wrong with your setup. > > Wolfgang. > > > > >> Moore soon. > >> > >> Wolfgang. > >>> Thanks a lot > >>> > >>> -- > >>> Javi Roman. > >>>
OK, the driver is working fine, ..., I'm so unlucky! :-( I have to find out what can be the problem with my board. Thank you very much for all your help!! greetings -- Javi Roman ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
