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] Any thing more to prove? Any idea? 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
