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.
-------------------------------------------------------------------------
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
bash-2.05b# . load-rtnet
rtai: decrementer frequency 5000000 Hz
rtai: mounting
rtai: mount done
==== RT memory manager v1.3 Loaded. ====
***** STARTING THE UP REAL TIME SCHEDULER WITH LINUX *****
***** FP SUPPORT AND READY FOR A PERIODIC TIMER *****
***<> LINUX TICK AT 100 (HZ) <>***
***<> CALIBRATED CPU FREQUENCY 5000000 (HZ) <>***
***<> CALIBRATED TIMER-INTERRUPT-TO-SCHEDULER LATENCY 2600 (ns) <>***
***<> CALIBRATED ONE SHOT SETUP TIME 400 (ns) <>***
RTDM Version 0.5.1
*** RTnet 0.7.1 - built on Jan 12 2007 22:25:56 ***
RTnet: initialising real-time networking
RTnet: stack-mgr started
RTDM: registered protocol device 2:2
RTDM: registered protocol device 17:2
RTnet: registered rteth0
RTnet: rteth0: FEC ENET Version 0.3, irq 9, addr 00:d0:93:80:03:54
bash-2.05b#
bash-2.05b#
bash-2.05b#
bash-2.05b# rtifconfig rteth0 up 172.16.0.50 netmask 255.255.255.0
bash-2.05b# rtifconfig
rteth0 Medium: Ethernet Hardware address: 00:D0:93:80:03:54
IP address: 172.16.0.50 Broadcast address: 172.16.0.255
UP BROADCAST RUNNING MTU: 1500
bash-2.05b# rtroute solicit 172.16.0.100 dev rteth0
bash-2.05b#
bash-2.05b# rtroute
Host Routing Table
Hash Destination HW Address Device
24 172.16.0.100 00:00:F0:92:7E:B7 rteth0
3F 172.16.0.255 FF:FF:FF:FF:FF:FF rteth0
bash-2.05b#
bash-2.05b# rtping 172.16.0.100
Real-time PING 172.16.0.100 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 time=0.0 us
64 bytes from 172.16.0.100: icmp_seq=2 time=0.0 us
64 bytes from 172.16.0.100: icmp_seq=3 time=0.0 us
64 bytes from 172.16.0.100: icmp_seq=4 time=0.0 us
--- 172.16.0.100 rtping statistics ---
4 packets transmitted, 4 received, 0% packet loss
-------------------------------------------------------------------------
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
