Hallo, some more comments to this Email...
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 Why is fec_restart called from fec_open()? If MDIO is disabled, fec_enet_restart() is called in fec_enet_init() with duplex = 0. The MDIO code is a reminder from the original code and is just left in place to simplify porting of MDIO later on. > 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. Wolfgang. ------------------------------------------------------------------------- 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
