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). > > Any thing more to prove? Any idea? > > I'm trying to get RTnet 0.7.1 built and running on my TQM866M board. > > Moore soon. > > Wolfgang. > > Thanks a lot > > > > -- > > 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 > > > > > > > > ------------------------------------------------------------------------- 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
