rtnet-developers — development-related list

[RTnet-developers] Socket RAW

[Jorge A. <j-a...@cr...>]

Jan,


I've looked in the af_packet.c file and i arrive to some conclusions for the RAW packet implementation, but i have some doubts regardind the rtskb struct.

Especialy in:

rtsckb.h - line 194
    /* link layer */
    union
    {
        struct ethhdr   *ethernet;
        unsigned char   *raw;
    } mac;

i know that  "struct ethhdr   *ethernet; " keeps the source and destination mac address of the frame, but wath values "unsigned char   *raw;" can have?


And another question,
Does not existe any field in the rtskb struct that has all the Ethernet frame inside (Destination Address, Source Address, Protocol, Data)? In the driver everything is divided right?


One thing that i'm thinking is reconstruct a buffer with all this information and return it to the user. This way the user has all the Ethernet frame in user space and can do anything he wants.


Please Comment my ideias.

Thanks
-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

[RTnet-developers] Real-Time Network Measurement

[Imre P. <imr...@gm...>]

We want to test our RTnet aplication to see if the timing is right.
Actually we find a page for Active Probing at
http://www.cubinlab.ee.unimelb.edu.au/probing/software.php#tsc-rt-linux
but they dealing with RTnet based on RTLinux.
Our environment: 2 PC with 2.6.15 kernel, RTAI-3.3-cv and RTnet 0.9.3
The NICs are RT8139.

Do you have some suggestions for us?

Thanks in Advance!

Imre Paniti

[RTnet-developers] SVN moved

[Jan K. <jan...@we...>]

Hi,

given that a consolidation of RTnet's hosting also has other advantages,
I hesitated no longer and migrated the subversion repository from ailing
berlios to sourceforge. The new URL for check-outs is now:

	https://svn.sourceforge.net/svnroot/rtnet

This covers both read-only and developer access. To obtain the trunk via
command line:

	svn co https://svn.sourceforge.net/svnroot/rtnet/trunk/rtnet

Developers with write access (at moment only Marc and me; Yuchen,
Wolfgang, please contact me with your SF-account name) can then issue
"svn ci" from that local repository and will be asked for their password
(you may want to override your username via "svn ci --username MYNAME ...=
").

To rebase your existing check-out, simply invoke

	svn switch --relocate YOUR-OLD-URL \
	https://svn.sourceforge.net/svnroot/rtnet/trunk/rtnet

See "svn info" for "YOUR-OLD-URL".

The first check-in already took place, and everything looks fine again.
Now only the backup has to be fixed as sourceforge uses rsync for this.

Jan

Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Chris Lightcap wrote:
> Hi Jan,
>=20
> I've modified a simple arcnet communication program to support the=20
> new real-time driver.. but I'm having a problem opening the socket=20
> (the first step, i know!) where the function returns an integer=20
> value of -97? The original program called the socket function with=20
> the following socket type and protocol and I've modified it as=20
> shown below.
>=20
> int sockfd =3D socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL)); //=20
> the original
>=20
> int sockfd =3D rt_dev_socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));=20
> // the modified
>=20
> I know that SOCK_PACKET is an outdated socket type but the=20
> alternative SOCK_RAW will not work either. I found in the=20
> rt_pci32.c driver that the arguments AF_INET and SOCK_DGRAM work=20
> but I need to use header information in the arcnet packets.
>=20
> Any suggestions?
>=20

Depends on what you really need for your arcnet app: RTnet's rtpacket
currently provide PF_PACKET:SOCK_DGRAM, i.e. "cooked" access to some
networking device. And this access is limited to a per-protocol basis,
which means no ETH_P_ALL. Moreover, it's a bit Ethernet-specific, see
rt_packet_recvmsg().

Some generalisation of the rtpacket socket interface will therefore be
required. Whether you also have to add ETH_P_ALL support, depends on
your application design. Currently, the core would demux incoming arcnet
protocols for you and and distribute them to different sockets
(registered via socket(PF_PACKET, SOCK_DGRAM, <protocol>)). ETH_P_ALL
would require exclusive device access because RTnet has currently no
means to clone incoming packets for multiple receivers. SOCK_RAW might
be necessary if there is no clean way to get all required arcnet header
informations through the SOCK_DGRAM interface.

Re-check your situation and suggest what you think it's best for your
scenario. Then we can see how to generalise your usage scenario and
integrate it cleanly.

Jan

Re: [RTnet-developers] arcnet driver

[Chris L. <ca...@uf...>]

Hi Jan,

I've modified a simple arcnet communication program to support the 
new real-time driver.. but I'm having a problem opening the socket 
(the first step, i know!) where the function returns an integer 
value of -97? The original program called the socket function with 
the following socket type and protocol and I've modified it as 
shown below.

int sockfd = socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL)); // 
the original

int sockfd = rt_dev_socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); 
// the modified

I know that SOCK_PACKET is an outdated socket type but the 
alternative SOCK_RAW will not work either. I found in the 
rt_pci32.c driver that the arguments AF_INET and SOCK_DGRAM work 
but I need to use header information in the arcnet packets.

Any suggestions?

Thanks for all of the help,
Chris Lightcap
University of Florida




On Fri Jul 14 12:31:27 EDT 2006, Jan Kiszka <jan...@we...> 
wrote:

> Chris Lightcap wrote:
>> 
>> Hi Jan,
>> 
>> I made the changes you suggested in your last response. I've 
>> exported
>> the rtdev_alloc so that I can use that with arcdev_setup in my 
>> driver.
>> (code shown below)
>> 
>> /* Setup a struct device for ARCnet. */
>> 
>> static void arcdev_setup(struct rtnet_device *dev)
>> {
>>     dev->type = ARPHRD_ARCNET;
>>     dev->hard_header_len = sizeof(struct archdr);
>>     dev->mtu = choose_mtu();
>>     dev->get_mtu = rt_hard_mtu; // RTNET
>> 
>>     dev->addr_len = ARCNET_ALEN;
>> 
>>     // dev->tx_queue_len = 100; // RTNET
>>     // dev->watchdog_timeo = TX_TIMEOUT;
>> 
>>     dev->broadcast[0] = 0x00;    // for us, broadcasts are 
>> address 0
>>         // New-style flags.
>> 
>>     dev->flags = IFF_BROADCAST;
>>         // Put in this stuff here, so we don't have to export 
>> the symbols to
>>     // the chipset drivers.
>>         dev->open = arcnet_open;
>>     dev->stop = arcnet_close;
>>     dev->hard_start_xmit = arcnet_send_packet;
>> 
>>     // dev->tx_timeout = arcnet_timeout;
>>     // dev->get_stats = arcnet_get_stats;
>> 
>>     dev->hard_header = arcnet_header;
>>     dev->rebuild_header = arcnet_rebuild_header;
>> }
>> 
>> struct rtnet_device *rt_alloc_arcdev(char *name)
>> {
>>     struct rtnet_device *dev;
>> 
>>     /*** RTnet ***/
>>            dev = rtdev_alloc(sizeof(struct arcnet_local)); // 
>> <-------
>>     if (!dev)
>>         return NULL;
>> 
>>     arcdev_setup(dev);
>> 
>>     memset(dev->broadcast, 0xFF, ARCNET_ALEN);
>>     strcpy(dev->name, "rteth%d");
>>         rtdev_alloc_name(dev, "rtarc%d");
>>     rt_rtdev_connect(dev, &RTDEV_manager);
>>     RTNET_SET_MODULE_OWNER(dev);
>>     dev->vers = RTDEV_VERS_2_0;
>> 
>>     /*** RTnet ***/
>> 
>>     if(dev) {
>>         struct arcnet_local *lp = (struct arcnet_local *) 
>> dev->priv;
>>         rtdm_lock_init(&lp->lock); /*** RTnet ***/
>>     }
>> 
>>     return dev;
>> }
>> 
>> We're not planning to run RTmac/TDMA over our RT arcnet so we've 
>> decided
>> to scratch the rtnet startup script and load the required 
>> modules in our
>> own script. Is there anything more that has to be done to load 
>> rtnet?
> 
> Yes and no. Explanation follows below.
> 
>> 
>> mknod /dev/rtnet c 10 240
>> 
>> ifconfig lo down
>> ifconfig arc0 down
>> 
>> insmod /usr/local/rtnet/modules/rtnet.ko
>> insmod /usr/local/rtnet/modules/rtipv4.ko
>> insmod /usr/local/rtnet/modules/rtpacket.ko
>> insmod /usr/local/rtnet/modules/rt_loopback.ko
>> 
>> insmod /usr/local/rtnet/modules/rt_arcnet.ko
>> insmod /usr/local/rtnet/modules/rt_com20020.ko
>> insmod /usr/local/rtnet/modules/rt_com20020-pci.ko
>> insmod /usr/local/rtnet/modules/rt_arc-rawmode.ko
>> 
>> /usr/local/rtnet/sbin/rtifconfig rtarc0 up 10.1.1.1
>> /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
>> 
>> It seems like everything loaded ok (no error messages) and 
>> here's the
>> output from dmesg | tail .. is the station address 00 a looming 
>> problem?
>> can I change this in the source file?
> 
> That looks arcnet-specific to me, and this is something I cannot 
> comment
> on due to lacking experience. I would compare the output with 
> standard
> Linux. Of course, understanding how the station addresses are 
> normally
> used will be even better. ;)
> 
>> 
>> lightcap@borelli:/usr/local/rtnet/sbin$ dmesg | tail
>> [4299263.969000] rt-arcnet: COM20020 PCI support
>> [4299263.970000] ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 
>> (level,
>> low) -> IRQ 21
>> [4299263.970000] rtarc0: Contemporary Controls
>> [4299264.272000] rtarc0: PCI COM20020: station 00h found at 
>> CC70h, IRQ 21.
>> [4299264.280000] rtarc0: Using CKP 64 - data rate 2.5 Mb/s.
>> [4299264.280000] RTnet: registered rtarc0
>> [4300094.481000] initializing loopback...
>> [4300094.481000] RTnet: registered rtlo
>> [4300094.511000] rt-arcnet: raw mode (`r') encapsulation support 
>> loaded.
>> [4300094.512000] rtarc0: WARNING!  Station address 00 is 
>> reserved for
>> broadcasts!
>> 
>> and surprisingly!
>> 
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtifconfig -a
>> rtarc0    Medium: unknown (7)
>                     ^^^^^^^
> Hah, this still needs fixing! :o>
> (see tools/rtifconfig.c)
> 
>>          IP address: 10.1.1.1  Broadcast address: 10.255.255.255
>>          UP BROADCAST RUNNING  MTU: 508
>> 
>> rtlo      Medium: Local Loopback
>>          IP address: 127.0.0.1
>>          UP LOOPBACK RUNNING  MTU: 1500
>> 
>> Here is the interesting part! I have a worst case rtt of 0.0 us 
>> when I
>> ping the local loopback. This can't be right. Even more strange 
>> is that
> 
> Let me guess: you run this over RTAI? Then you did not start the 
> system
> timer /somehow/. Normally, this is done by rtcfg.ko or tdma.ko. 
> If those
> modules aren't loaded, your application has to do this. But as 
> you do
> not have any application yet: simply insmod rtcfg.ko. This will 
> start
> the timer while rtcfg remains passive otherwise.
> 
>> I can ping the arcnet card, which I thought was only possible 
>> for TCP/IP
>> devices. What should I set for the IP address of my arcnet card; 
>> should
>> I leave it empty? And the big question is how can I test the 
>> performance
>> of the new arcnet driver without implementing it in our robot 
>> control
>> software? I have Ethereal but I it would be helpful if you had an
>> example program.
> 
> Well, if it is transparent to the rest of the RTnet stack (and 
> this
> seems to be the case), rtping would be a good start. Another 
> performance
> tester are the rtt-* examples under examples/xenomai/posix. 
> Teresa
> Noviello started a RTAI port recently, but I don't know the 
> current status.
> 
>> 
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 127.0.0.1
>> Real-time PING 127.0.0.1 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=10 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=11 time=0.0 us
>> 
>> --- 127.0.0.1 rtping statistics ---
>> 11 packets transmitted, 11 received, 0% packet loss
>> worst case rtt = 0.0 us
>> 
>> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 10.1.1.1
>> Real-time PING 10.1.1.1 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
>> 64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us
>> 
>> --- 10.1.1.1 rtping statistics ---
>> 9 packets transmitted, 9 received, 0% packet loss
>> worst case rtt = 0.0 us
>> 
>> 
>> Thanks again! I'm making great process thanks to your quick 
>> responses.
> 
> I'm just eagerly awaiting your patches... :)
> 
> Jan
> 
> 
> 



--
LIGHTCAP,CHRISTOPHER A

Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Chris Lightcap wrote:
>=20
> Hi Jan,
>=20
> I made the changes you suggested in your last response. I've exported
> the rtdev_alloc so that I can use that with arcdev_setup in my driver.
> (code shown below)
>=20
> /* Setup a struct device for ARCnet. */
>=20
> static void arcdev_setup(struct rtnet_device *dev)
> {
>     dev->type =3D ARPHRD_ARCNET;
>     dev->hard_header_len =3D sizeof(struct archdr);
>     dev->mtu =3D choose_mtu();
>     dev->get_mtu =3D rt_hard_mtu; // RTNET
>=20
>     dev->addr_len =3D ARCNET_ALEN;
>=20
>     // dev->tx_queue_len =3D 100; // RTNET
>     // dev->watchdog_timeo =3D TX_TIMEOUT;
>=20
>     dev->broadcast[0] =3D 0x00;    // for us, broadcasts are address 0
>    =20
>     // New-style flags.
>=20
>     dev->flags =3D IFF_BROADCAST;
>    =20
>     // Put in this stuff here, so we don't have to export the symbols t=
o
>     // the chipset drivers.
>    =20
>     dev->open =3D arcnet_open;
>     dev->stop =3D arcnet_close;
>     dev->hard_start_xmit =3D arcnet_send_packet;
>=20
>     // dev->tx_timeout =3D arcnet_timeout;
>     // dev->get_stats =3D arcnet_get_stats;
>=20
>     dev->hard_header =3D arcnet_header;
>     dev->rebuild_header =3D arcnet_rebuild_header;
> }
>=20
> struct rtnet_device *rt_alloc_arcdev(char *name)
> {
>     struct rtnet_device *dev;
>=20
>     /*** RTnet ***/
>       =20
>     dev =3D rtdev_alloc(sizeof(struct arcnet_local)); // <-------
>     if (!dev)
>         return NULL;
>=20
>     arcdev_setup(dev);
>=20
>     memset(dev->broadcast, 0xFF, ARCNET_ALEN);
>     strcpy(dev->name, "rteth%d");
>    =20
>     rtdev_alloc_name(dev, "rtarc%d");
>     rt_rtdev_connect(dev, &RTDEV_manager);
>     RTNET_SET_MODULE_OWNER(dev);
>     dev->vers =3D RTDEV_VERS_2_0;
>=20
>     /*** RTnet ***/
>=20
>     if(dev) {
>         struct arcnet_local *lp =3D (struct arcnet_local *) dev->priv;
>         rtdm_lock_init(&lp->lock); /*** RTnet ***/
>     }
>=20
>     return dev;
> }
>=20
> We're not planning to run RTmac/TDMA over our RT arcnet so we've decide=
d
> to scratch the rtnet startup script and load the required modules in ou=
r
> own script. Is there anything more that has to be done to load rtnet?

Yes and no. Explanation follows below.

>=20
> mknod /dev/rtnet c 10 240
>=20
> ifconfig lo down
> ifconfig arc0 down
>=20
> insmod /usr/local/rtnet/modules/rtnet.ko
> insmod /usr/local/rtnet/modules/rtipv4.ko
> insmod /usr/local/rtnet/modules/rtpacket.ko
> insmod /usr/local/rtnet/modules/rt_loopback.ko
>=20
> insmod /usr/local/rtnet/modules/rt_arcnet.ko
> insmod /usr/local/rtnet/modules/rt_com20020.ko
> insmod /usr/local/rtnet/modules/rt_com20020-pci.ko
> insmod /usr/local/rtnet/modules/rt_arc-rawmode.ko
>=20
> /usr/local/rtnet/sbin/rtifconfig rtarc0 up 10.1.1.1
> /usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1
>=20
> It seems like everything loaded ok (no error messages) and here's the
> output from dmesg | tail .. is the station address 00 a looming problem=
?
> can I change this in the source file?

That looks arcnet-specific to me, and this is something I cannot comment
on due to lacking experience. I would compare the output with standard
Linux. Of course, understanding how the station addresses are normally
used will be even better. ;)

>=20
> lightcap@borelli:/usr/local/rtnet/sbin$ dmesg | tail
> [4299263.969000] rt-arcnet: COM20020 PCI support
> [4299263.970000] ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 (level,
> low) -> IRQ 21
> [4299263.970000] rtarc0: Contemporary Controls
> [4299264.272000] rtarc0: PCI COM20020: station 00h found at CC70h, IRQ =
21.
> [4299264.280000] rtarc0: Using CKP 64 - data rate 2.5 Mb/s.
> [4299264.280000] RTnet: registered rtarc0
> [4300094.481000] initializing loopback...
> [4300094.481000] RTnet: registered rtlo
> [4300094.511000] rt-arcnet: raw mode (`r') encapsulation support loaded=
=2E
> [4300094.512000] rtarc0: WARNING!  Station address 00 is reserved for
> broadcasts!
>=20
> and surprisingly!
>=20
> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtifconfig -a
> rtarc0    Medium: unknown (7)
                    ^^^^^^^
Hah, this still needs fixing! :o>
(see tools/rtifconfig.c)

>          IP address: 10.1.1.1  Broadcast address: 10.255.255.255
>          UP BROADCAST RUNNING  MTU: 508
>=20
> rtlo      Medium: Local Loopback
>          IP address: 127.0.0.1
>          UP LOOPBACK RUNNING  MTU: 1500
>=20
> Here is the interesting part! I have a worst case rtt of 0.0 us when I
> ping the local loopback. This can't be right. Even more strange is that=


Let me guess: you run this over RTAI? Then you did not start the system
timer /somehow/. Normally, this is done by rtcfg.ko or tdma.ko. If those
modules aren't loaded, your application has to do this. But as you do
not have any application yet: simply insmod rtcfg.ko. This will start
the timer while rtcfg remains passive otherwise.

> I can ping the arcnet card, which I thought was only possible for TCP/I=
P
> devices. What should I set for the IP address of my arcnet card; should=

> I leave it empty? And the big question is how can I test the performanc=
e
> of the new arcnet driver without implementing it in our robot control
> software? I have Ethereal but I it would be helpful if you had an
> example program.

Well, if it is transparent to the rest of the RTnet stack (and this
seems to be the case), rtping would be a good start. Another performance
tester are the rtt-* examples under examples/xenomai/posix. Teresa
Noviello started a RTAI port recently, but I don't know the current statu=
s.

>=20
> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 127.0.0.1
> Real-time PING 127.0.0.1 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=3D1 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D2 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D3 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D4 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D5 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D6 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D7 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D8 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D9 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D10 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D11 time=3D0.0 us
>=20
> --- 127.0.0.1 rtping statistics ---
> 11 packets transmitted, 11 received, 0% packet loss
> worst case rtt =3D 0.0 us
>=20
> lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 10.1.1.1
> Real-time PING 10.1.1.1 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=3D1 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D2 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D3 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D4 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D5 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D6 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D7 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D8 time=3D0.0 us
> 64 bytes from 127.0.0.1: icmp_seq=3D9 time=3D0.0 us
>=20
> --- 10.1.1.1 rtping statistics ---
> 9 packets transmitted, 9 received, 0% packet loss
> worst case rtt =3D 0.0 us
>=20
>=20
> Thanks again! I'm making great process thanks to your quick responses.

I'm just eagerly awaiting your patches... :)

Jan

Re: [RTnet-developers] arcnet driver

[Chris L. <ca...@uf...>]

Hi Jan,

I made the changes you suggested in your last response. I've 
exported the rtdev_alloc so that I can use that with arcdev_setup 
in my driver. (code shown below)

/* Setup a struct device for ARCnet. */

static void arcdev_setup(struct rtnet_device *dev)
{
	dev->type = ARPHRD_ARCNET;
	dev->hard_header_len = sizeof(struct archdr);
	dev->mtu = choose_mtu();
	dev->get_mtu = rt_hard_mtu; // RTNET

	dev->addr_len = ARCNET_ALEN;

	// dev->tx_queue_len = 100; // RTNET
	// dev->watchdog_timeo = TX_TIMEOUT;

	dev->broadcast[0] = 0x00;	// for us, broadcasts are address 0
	
	// New-style flags.

	dev->flags = IFF_BROADCAST;
	
	// Put in this stuff here, so we don't have to export the symbols 
to
	// the chipset drivers.
	
	dev->open = arcnet_open;
	dev->stop = arcnet_close;
	dev->hard_start_xmit = arcnet_send_packet;

	// dev->tx_timeout = arcnet_timeout;
	// dev->get_stats = arcnet_get_stats;

	dev->hard_header = arcnet_header;
	dev->rebuild_header = arcnet_rebuild_header;
}

struct rtnet_device *rt_alloc_arcdev(char *name)
{
	struct rtnet_device *dev;

	/*** RTnet ***/
		
	dev = rtdev_alloc(sizeof(struct arcnet_local)); // <-------
	if (!dev)
     	return NULL;

	arcdev_setup(dev);

	memset(dev->broadcast, 0xFF, ARCNET_ALEN);
	strcpy(dev->name, "rteth%d");
	
	rtdev_alloc_name(dev, "rtarc%d");
	rt_rtdev_connect(dev, &RTDEV_manager);
	RTNET_SET_MODULE_OWNER(dev);
	dev->vers = RTDEV_VERS_2_0;

	/*** RTnet ***/

	if(dev) {
		struct arcnet_local *lp = (struct arcnet_local *) dev->priv;
		rtdm_lock_init(&lp->lock); /*** RTnet ***/
	}

	return dev;
}

We're not planning to run RTmac/TDMA over our RT arcnet so we've 
decided to scratch the rtnet startup script and load the required 
modules in our own script. Is there anything more that has to be 
done to load rtnet?

mknod /dev/rtnet c 10 240

ifconfig lo down
ifconfig arc0 down

insmod /usr/local/rtnet/modules/rtnet.ko
insmod /usr/local/rtnet/modules/rtipv4.ko
insmod /usr/local/rtnet/modules/rtpacket.ko
insmod /usr/local/rtnet/modules/rt_loopback.ko

insmod /usr/local/rtnet/modules/rt_arcnet.ko
insmod /usr/local/rtnet/modules/rt_com20020.ko
insmod /usr/local/rtnet/modules/rt_com20020-pci.ko
insmod /usr/local/rtnet/modules/rt_arc-rawmode.ko

/usr/local/rtnet/sbin/rtifconfig rtarc0 up 10.1.1.1
/usr/local/rtnet/sbin/rtifconfig rtlo up 127.0.0.1

It seems like everything loaded ok (no error messages) and here's 
the output from dmesg | tail .. is the station address 00 a 
looming problem? can I change this in the source file?

lightcap@borelli:/usr/local/rtnet/sbin$ dmesg | tail
[4299263.969000] rt-arcnet: COM20020 PCI support
[4299263.970000] ACPI: PCI Interrupt 0000:04:02.0[A] -> GSI 18 
(level, low) -> IRQ 21
[4299263.970000] rtarc0: Contemporary Controls
[4299264.272000] rtarc0: PCI COM20020: station 00h found at CC70h, 
IRQ 21.
[4299264.280000] rtarc0: Using CKP 64 - data rate 2.5 Mb/s.
[4299264.280000] RTnet: registered rtarc0
[4300094.481000] initializing loopback...
[4300094.481000] RTnet: registered rtlo
[4300094.511000] rt-arcnet: raw mode (`r') encapsulation support 
loaded.
[4300094.512000] rtarc0: WARNING!  Station address 00 is reserved 
for broadcasts!

and surprisingly!

lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtifconfig -a
rtarc0    Medium: unknown (7)
          IP address: 10.1.1.1  Broadcast address: 10.255.255.255
          UP BROADCAST RUNNING  MTU: 508

rtlo      Medium: Local Loopback
          IP address: 127.0.0.1
          UP LOOPBACK RUNNING  MTU: 1500

Here is the interesting part! I have a worst case rtt of 0.0 us 
when I ping the local loopback. This can't be right. Even more 
strange is that I can ping the arcnet card, which I thought was 
only possible for TCP/IP devices. What should I set for the IP 
address of my arcnet card; should I leave it empty? And the big 
question is how can I test the performance of the new arcnet 
driver without implementing it in our robot control software? I 
have Ethereal but I it would be helpful if you had an example 
program.

lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 127.0.0.1
Real-time PING 127.0.0.1 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=10 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=11 time=0.0 us

--- 127.0.0.1 rtping statistics ---
11 packets transmitted, 11 received, 0% packet loss
worst case rtt = 0.0 us

lightcap@borelli:/usr/local/rtnet/sbin$ sudo ./rtping 10.1.1.1
Real-time PING 10.1.1.1 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=2 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=3 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=4 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=5 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=6 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=7 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=8 time=0.0 us
64 bytes from 127.0.0.1: icmp_seq=9 time=0.0 us

--- 10.1.1.1 rtping statistics ---
9 packets transmitted, 9 received, 0% packet loss
worst case rtt = 0.0 us


Thanks again! I'm making great process thanks to your quick 
responses.

Chris Lightcap
University of Florida




On Thu Jul 13 17:56:12 EDT 2006, Jan Kiszka <jan...@we...> 
wrote:

> Hi Christoper,
> 
> LIGHTCAP,CHRISTOPHER A wrote:
>> 
>> Jan,
>> 
>> Thanks for such a quick response! We've made good progress with 
>> the
> 
> Indeed, I'm impressed!
> 
>> RTnet Arcnet driver but have a few questions about code which 
>> doesn't
>> quite match up to the existing examples.
>> 
>> And I have little experience with designing network drivers (or 
>> any
>> driver!) .. therefore the questions might seem basic.
>> 
>> 1.) The original arcnet driver does not call alloc_etherdev but 
>> rather
>> alloc_netdev (shown below). Can I still change this function 
>> call like
>> suggested in your porting documenation? What effect will this 
>> have on
>> the program?
>> 
>> BEFORE
>> 
>> struct net_device *alloc_arcdev(char *name)
>> {
>>     struct net_device *dev;
>> 
>>     dev = alloc_netdev(sizeof(struct arcnet_local),
>>                name && *name ? name : "arc%d", arcdev_setup);
>>     if(dev) {
>>         struct arcnet_local *lp = (struct arcnet_local *) 
>> dev->priv;
>>         spin_lock_init(&lp->lock);
>>     }
>> 
>>     return dev;
>> }
>> 
>> AFTER
>> 
>> struct rtnet_device *alloc_arcdev(char *name)
>> {
>>     struct rtnet_device *dev;
>> 
>>     /*** RTnet ***/
>>     dev = rt_alloc_etherdev(sizeof(struct arcnet_local)); // 
>> etherdev?
>>         rtdev_alloc_name(dev, "rtarc%d");
>>     rt_rtdev_connect(dev, &RTDEV_manager);
>>     RTNET_SET_MODULE_OWNER(dev);
>>     dev->vers = RTDEV_VERS_2_0;
>>     /*** RTnet ***/
>> 
>>     if(dev) {
>>         struct arcnet_local *lp = (struct arcnet_local *) 
>> dev->priv;
>>         rtdm_lock_init(&lp->lock); /*** RTnet ***/
>>     }
>> 
>>     return dev;
>> }
> 
> We have rtdev_alloc instead, but that's not exported so far. If 
> you need
> it, it's trivial to add such an export (i.e. feel free to add 
> this to
> your patch). In this case, you will likely have to do a similar
> initialisation of the device structure like it is now done in
> rt_alloc_etherdev for Ethernet. I guess your handler arcdev_setup 
> is
> responsible for this in the original driver.
> 
>> 
>> 2.) In your example, you initialize the skb_pool in the probe 
>> function
> 
> Which example do you mean?
> 
>> and if the return value is less than twice the ring size then you
>> release the skb_pool and call a few 'cleanup' functions.
>> 
>> e.g.     pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, 
>> lp->dma_addr);
>> 
>>    I'm not sure how it works, but I cannot this function because 
>> the
>> struct arcnet_local does not have a field called 'dma_addr'. So 
>> my
>> question is .. is dma_addr disguised under another name in the
>> arcnet_local struct? and if not do I even need to call this 
>> function?
> 
> That's definitely driver-specific. If you did not request this 
> kind of
> resource earlier, you do not have to release it here on error. 
> Rather
> check your driver carefully what might have to be cleaned up when
> something fails.
> 
>> [...]
>> 
>> 3.) Ok. last question. It seems like I have a problem with module
>> dependencies. The arcnet driver is set up to be loaded as four 
>> separate
>> modules: arcnet.ko (the foundation), arc-rawmode.ko (provides 
>> rawmode
>> encapsulation), com20020.ko (support for chipset), and 
>> com20020-pci.ko
>> (support for pci-board).
>> 
>> I've done my homework and created four rt modules that compile 
>> and load
>> into the kernel.. but the problem is that I cannot get them to 
>> load with
>> 'rtnet start'. How do I specify dependencies in the 'rtnet.conf' 
>> file?
>> My dilemna is that if I specify com20020-pci without any extra 
>> work..
>> the program will not run because it cannot load the module 
>> without its
>> dependencies.. BUT I cannot load rt_arcnet.ko and rt_com20020.ko 
>> before
>> running 'rtnet start' because they both depend on the module 
>> rtnet!!
> 
> Yeah, I see. This actually reminds me of the fact that the 
> installation
> process and, as a result, the startup scripting need some 
> renovation.
> The way it is now dates back to the days where RT applications 
> where
> typically kernel modules as well. In fact we should have the same
> problem with the recently added RT-WLAN driver as well. Daniel 
> just
> didn't test a full RTnet setup yet as far as I heard.
> 
> If we assume that modules go to 
> /lib/modules/<kernel-version>/rtnet by
> default e.g. and that depmod will be executed (or we trigger its
> execution), then modprobe could be used in the startup script, 
> and
> missing components will get dragged in automatically - kind of 
> standard...
> 
>> 
>> So I feel like I'm in a bit of a catch-22. Please tell me how to 
>> get
>> around this problem.
> 
> Well, as an intermediate solution we could add another variable 
> to
> rtnet.conf, let's say RT_ADDON_MODULES, that lists all modules 
> that have
> to be loaded after rtnet.ko but before the driver. This could 
> also
> include rtpacket.ko, thus making this component optional wrt the 
> rtnet
> start script. A simple
> 
> for mod in $RT_ADDON_MODULES; do insmod 
> $RTNET_MOD/$mod$MODULE_EXT; done
> 
> would take care of the list in the script. Do you have scripting
> experiences to add this?
> 
> But we definitely need refactoring of the installation process 
> and the
> startup script. Many people already asked for multi-device setup,
> something that is not addressed by the current script design. I 
> have no
> ideas on this yet, though.
> 
> 
> Hmm, BTW, do you actually *need* the start script as it is at 
> all???
> Will you run RTmac/TDMA over ARCNET (because that is what the 
> script is
> mostly about!)? Maybe it's an even easier way for you to write 
> your own
> startup/cleanup script then, just by picking up the interesting 
> pieces
> from existing code and docs.
> 
>> 
>> Thank you so much for your help.
>> 
>> Chris Lightcap
>> University of Florida
>> 
> 
> Looking forward to hear about the first successful experiments!
> 
> Jan
> 
> 

Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Hi Christoper,

LIGHTCAP,CHRISTOPHER A wrote:
>=20
> Jan,
>=20
> Thanks for such a quick response! We've made good progress with the

Indeed, I'm impressed!

> RTnet Arcnet driver but have a few questions about code which doesn't
> quite match up to the existing examples.
>=20
> And I have little experience with designing network drivers (or any
> driver!) .. therefore the questions might seem basic.
>=20
> 1.) The original arcnet driver does not call alloc_etherdev but rather
> alloc_netdev (shown below). Can I still change this function call like
> suggested in your porting documenation? What effect will this have on
> the program?
>=20
> BEFORE
>=20
> struct net_device *alloc_arcdev(char *name)
> {
>     struct net_device *dev;
>=20
>     dev =3D alloc_netdev(sizeof(struct arcnet_local),
>                name && *name ? name : "arc%d", arcdev_setup);
>     if(dev) {
>         struct arcnet_local *lp =3D (struct arcnet_local *) dev->priv;
>         spin_lock_init(&lp->lock);
>     }
>=20
>     return dev;
> }
>=20
> AFTER
>=20
> struct rtnet_device *alloc_arcdev(char *name)
> {
>     struct rtnet_device *dev;
>=20
>     /*** RTnet ***/
>     dev =3D rt_alloc_etherdev(sizeof(struct arcnet_local)); // etherdev=
?
>    =20
>     rtdev_alloc_name(dev, "rtarc%d");
>     rt_rtdev_connect(dev, &RTDEV_manager);
>     RTNET_SET_MODULE_OWNER(dev);
>     dev->vers =3D RTDEV_VERS_2_0;
>     /*** RTnet ***/
>=20
>     if(dev) {
>         struct arcnet_local *lp =3D (struct arcnet_local *) dev->priv;
>         rtdm_lock_init(&lp->lock); /*** RTnet ***/
>     }
>=20
>     return dev;
> }

We have rtdev_alloc instead, but that's not exported so far. If you need
it, it's trivial to add such an export (i.e. feel free to add this to
your patch). In this case, you will likely have to do a similar
initialisation of the device structure like it is now done in
rt_alloc_etherdev for Ethernet. I guess your handler arcdev_setup is
responsible for this in the original driver.

>=20
> 2.) In your example, you initialize the skb_pool in the probe function

Which example do you mean?

> and if the return value is less than twice the ring size then you
> release the skb_pool and call a few 'cleanup' functions.
>=20
> e.g.     pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, lp->dma_addr=
);
>=20
>    I'm not sure how it works, but I cannot this function because the
> struct arcnet_local does not have a field called 'dma_addr'. So my
> question is .. is dma_addr disguised under another name in the
> arcnet_local struct? and if not do I even need to call this function?

That's definitely driver-specific. If you did not request this kind of
resource earlier, you do not have to release it here on error. Rather
check your driver carefully what might have to be cleaned up when
something fails.

> [...]
>=20
> 3.) Ok. last question. It seems like I have a problem with module
> dependencies. The arcnet driver is set up to be loaded as four separate=

> modules: arcnet.ko (the foundation), arc-rawmode.ko (provides rawmode
> encapsulation), com20020.ko (support for chipset), and com20020-pci.ko
> (support for pci-board).
>=20
> I've done my homework and created four rt modules that compile and load=

> into the kernel.. but the problem is that I cannot get them to load wit=
h
> 'rtnet start'. How do I specify dependencies in the 'rtnet.conf' file?
> My dilemna is that if I specify com20020-pci without any extra work..
> the program will not run because it cannot load the module without its
> dependencies.. BUT I cannot load rt_arcnet.ko and rt_com20020.ko before=

> running 'rtnet start' because they both depend on the module rtnet!!

Yeah, I see. This actually reminds me of the fact that the installation
process and, as a result, the startup scripting need some renovation.
The way it is now dates back to the days where RT applications where
typically kernel modules as well. In fact we should have the same
problem with the recently added RT-WLAN driver as well. Daniel just
didn't test a full RTnet setup yet as far as I heard.

If we assume that modules go to /lib/modules/<kernel-version>/rtnet by
default e.g. and that depmod will be executed (or we trigger its
execution), then modprobe could be used in the startup script, and
missing components will get dragged in automatically - kind of standard..=
=2E

>=20
> So I feel like I'm in a bit of a catch-22. Please tell me how to get
> around this problem.

Well, as an intermediate solution we could add another variable to
rtnet.conf, let's say RT_ADDON_MODULES, that lists all modules that have
to be loaded after rtnet.ko but before the driver. This could also
include rtpacket.ko, thus making this component optional wrt the rtnet
start script. A simple

for mod in $RT_ADDON_MODULES; do insmod $RTNET_MOD/$mod$MODULE_EXT; done

would take care of the list in the script. Do you have scripting
experiences to add this?

But we definitely need refactoring of the installation process and the
startup script. Many people already asked for multi-device setup,
something that is not addressed by the current script design. I have no
ideas on this yet, though.


Hmm, BTW, do you actually *need* the start script as it is at all???
Will you run RTmac/TDMA over ARCNET (because that is what the script is
mostly about!)? Maybe it's an even easier way for you to write your own
startup/cleanup script then, just by picking up the interesting pieces
from existing code and docs.

>=20
> Thank you so much for your help.
>=20
> Chris Lightcap
> University of Florida
>=20

Looking forward to hear about the first successful experiments!

Jan

Re: [RTnet-developers] arcnet driver

[LIGHTCAP,CHRISTOPHER A <ca...@uf...>]

Jan,

Thanks for such a quick response! We've made good progress with 
the RTnet Arcnet driver but have a few questions about code which 
doesn't quite match up to the existing examples.

And I have little experience with designing network drivers (or 
any driver!) .. therefore the questions might seem basic.

1.) The original arcnet driver does not call alloc_etherdev but 
rather alloc_netdev (shown below). Can I still change this 
function call like suggested in your porting documenation? What 
effect will this have on the program?

BEFORE

struct net_device *alloc_arcdev(char *name)
{
	struct net_device *dev;

	dev = alloc_netdev(sizeof(struct arcnet_local),
			   name && *name ? name : "arc%d", arcdev_setup);
	if(dev) {
		struct arcnet_local *lp = (struct arcnet_local *) dev->priv;
		spin_lock_init(&lp->lock);
	}

	return dev;
}

AFTER

struct rtnet_device *alloc_arcdev(char *name)
{
	struct rtnet_device *dev;

	/*** RTnet ***/
	dev = rt_alloc_etherdev(sizeof(struct arcnet_local)); // 
etherdev?
	
	rtdev_alloc_name(dev, "rtarc%d");
	rt_rtdev_connect(dev, &RTDEV_manager);
	RTNET_SET_MODULE_OWNER(dev);
	dev->vers = RTDEV_VERS_2_0;
	/*** RTnet ***/

	if(dev) {
		struct arcnet_local *lp = (struct arcnet_local *) dev->priv;
		rtdm_lock_init(&lp->lock); /*** RTnet ***/
	}

	return dev;
}

2.) In your example, you initialize the skb_pool in the probe 
function and if the return value is less than twice the ring size 
then you release the skb_pool and call a few 'cleanup' functions.

e.g.     pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, 
lp->dma_addr);

    I'm not sure how it works, but I cannot this function because 
the struct arcnet_local does not have a field called 'dma_addr'. 
So my question is .. is dma_addr disguised under another name in 
the arcnet_local struct? and if not do I even need to call this 
function?

static int __devinit com20020pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
{
	struct rtnet_device *dev;
	struct arcnet_local *lp;
	int ioaddr, err;

	/*** RTnet ***/
	
	cards_found++;
    	if (cards[cards_found] == 0)
     	return -ENODEV;

	/*** RTnet ***/
	
	if (pci_enable_device(pdev))
		return -EIO;
	dev = alloc_arcdev(device);
	if (!dev)
		return -ENOMEM;
	lp = dev->priv;

	pci_set_drvdata(pdev, dev);

	// SOHARD needs PCI base addr 4
	if (pdev->vendor==0x10B5) {
		BUGMSG(D_NORMAL, "SOHARD\n");
		ioaddr = pci_resource_start(pdev, 4);
	}
	else {
		BUGMSG(D_NORMAL, "Contemporary Controls\n");
		ioaddr = pci_resource_start(pdev, 2);
	}

	if (!request_region(ioaddr, ARCNET_TOTAL_SIZE, "com20020-pci")) 
{
		BUGMSG(D_INIT, "IO region %xh-%xh already allocated.\n",
		       ioaddr, ioaddr + ARCNET_TOTAL_SIZE - 1);
		err = -EBUSY;
		goto out_dev;
	}

	/*** RTnet ***/
	if (rtskb_pool_init(&lp->skb_pool, RX_RING_SIZE*2) < 
RX_RING_SIZE*2) {
		rtskb_pool_release(&lp->skb_pool);
--------->   // pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, 
lp->dma_addr);
		release_region(ioaddr, ARCNET_TOTAL_SIZE);
		rtdev_free(dev);
     	return -ENOMEM;
        }
	/*** RTnet ***/

	// Dummy access after Reset
	// ARCNET controller needs this access to detect bustype
	outb(0x00,ioaddr+1);
	inb(ioaddr+1);

	dev->base_addr = ioaddr;
	dev->irq = pdev->irq;
	dev->dev_addr[0] = node;
	lp->card_name = "PCI COM20020";
	lp->card_flags = id->driver_data;
	lp->backplane = backplane;
	lp->clockp = clockp & 7;
	lp->clockm = clockm & 3;
	lp->timeout = timeout;
	lp->hw.owner = THIS_MODULE;

	if (ASTATUS() == 0xFF) {
		BUGMSG(D_NORMAL, "IO address %Xh was reported by PCI BIOS, "
		       "but seems empty!\n", ioaddr);
		err = -EIO;
		goto out_port;
	}
	
	if (com20020_check(dev)) {
		err = -EIO;
		goto out_port;
	}

	if ((err = com20020_found(dev, SA_SHIRQ)) != 0)
	        goto out_port;

	return 0;

out_port:
	release_region(ioaddr, ARCNET_TOTAL_SIZE);
out_dev:
	rtdev_free(dev);
	return err;
}

     here's a snapshot of the arcnet_local struct ...

struct arcnet_local {
	struct net_device_stats stats;

	uint8_t config,		/* current value of CONFIG register */
		timeout,	/* Extended timeout for COM20020 */
		backplane,	/* Backplane flag for COM20020 */
		clockp,		/* COM20020 clock divider */
		clockm,		/* COM20020 clock multiplier flag */
		setup,		/* Contents of setup1 register */
		setup2,		/* Contents of setup2 register */
		intmask;	/* current value of INTMASK register */
	uint8_t default_proto[256];	/* default encap to use for each host 
*/
	int	cur_tx,		/* buffer used by current transmit, or -1 */
		next_tx,	/* buffer where a packet is ready to send */
		cur_rx;		/* current receive buffer */
	int	lastload_dest,	/* can last loaded packet be acked? */
		lasttrans_dest;	/* can last TX'd packet be acked? */
	int	timed_out;	/* need to process TX timeout and drop packet */
	unsigned long last_timeout;	/* time of last reported timeout */
	char *card_name;	/* card ident string */
	int card_flags;		/* special card features */

	/*** RTnet ***/

        struct rtskb *tx_skbuff[TX_RING_SIZE];
        struct rtskb *rx_skbuff[RX_RING_SIZE];
        struct rtskb_queue skb_pool;

        rtdm_irq_t irq_handle;

	/*** RTnet ***/

	/* On preemtive and SMB a lock is needed */

	rtdm_lock_t lock;

	/*
	 * Buffer management: an ARCnet card has 4 x 512-byte buffers, 
each of
	 * which can be used for either sending or receiving.  The new 
dynamic
	 * buffer management routines use a simple circular queue of 
available
	 * buffers, and take them as they're needed.  This way, we 
simplify
	 * situations in which we (for example) want to pre-load a 
transmit
	 * buffer, or start receiving while we copy a received packet to
	 * memory.
	 *
	 * The rules: only the interrupt handler is allowed to _add_ 
buffers to
	 * the queue; thus, this doesn't require a lock.  Both the 
interrupt
	 * handler and the transmit function will want to _remove_ 
buffers, so
	 * we need to handle the situation where they try to do it at the 
same
	 * time.
	 *
	 * If next_buf == first_free_buf, the queue is empty.  Since 
there are
	 * only four possible buffers, the queue should never be full.
	 */
	atomic_t buf_lock;
	int buf_queue[5];
	int next_buf, first_free_buf;

	/* network "reconfiguration" handling */
	time_t first_recon,		/* time of "first" RECON message to count 
*/
		last_recon;		/* time of most recent RECON */
	int num_recons;		/* number of RECONs between first and last. */
	bool network_down;		/* do we think the network is down? */

	bool excnak_pending;	/* We just got an excesive nak interrupt */

	struct {
		uint16_t sequence;	/* sequence number (incs with each packet) 
*/
		uint16_t aborted_seq;

		struct Incoming incoming[256];	/* one from each address */
	} rfc1201;

	/* really only used by rfc1201, but we'll pretend it's not */
	struct Outgoing outgoing;	/* packet currently being sent */

	/* hardware-specific functions */
	struct {
		struct module *owner;
		void (*command) (struct rtnet_device * dev, int cmd);
		int (*status) (struct rtnet_device * dev);
		void (*intmask) (struct rtnet_device * dev, int mask);
		bool (*reset) (struct rtnet_device * dev, bool really_reset);
		void (*open) (struct rtnet_device * dev);
		void (*close) (struct rtnet_device * dev);

		void (*copy_to_card) (struct rtnet_device * dev, int bufnum, int 
offset,
				      void *buf, int count);
		void (*copy_from_card) (struct rtnet_device * dev, int bufnum, 
int offset,
					void *buf, int count);
	} hw;

	void __iomem *mem_start;	/* pointer to ioremap'ed MMIO */
};

     and if you're curious com20020_found looks like this ...

/* Set up the struct rtnet_device associated with this card.  
Called after
 * probing succeeds.
 */
int com20020_found(struct rtnet_device *dev, int shared)
{
	struct arcnet_local *lp;
	int ioaddr = dev->base_addr;
	int retval;

	/* Initialize the rest of the device structure. */

	lp = dev->priv;

	lp->hw.owner = THIS_MODULE;
	lp->hw.command = com20020_command;
	lp->hw.status = com20020_status;
	lp->hw.intmask = com20020_setmask;
	lp->hw.reset = com20020_reset;
	lp->hw.copy_to_card = com20020_copy_to_card;
	lp->hw.copy_from_card = com20020_copy_from_card;
	lp->hw.close = com20020_close;

	// dev->set_multicast_list = com20020_set_mc_list; /*** RTNET 
***/

	if (!dev->dev_addr[0])
		dev->dev_addr[0] = inb(ioaddr + BUS_ALIGN*8);	/* FIXME: do this 
some other way! (not written by me - Chris) */

	SET_SUBADR(SUB_SETUP1);
	outb(lp->setup, _XREG);

	if (lp->card_flags & ARC_CAN_10MBIT)
	{
		SET_SUBADR(SUB_SETUP2);
		outb(lp->setup2, _XREG);
	
		/* must now write the magic "restart operation" command */
		mdelay(1);
		outb(0x18, _COMMAND);
	}

	lp->config = 0x20 | (lp->timeout << 3) | (lp->backplane << 2) | 
1;
	/* Default 0x38 + register: Node ID */
	SETCONF;
	outb(dev->dev_addr[0], _XREG);

	/*** RTnet ***/

	/* reserve the irq */
	/*if (request_irq(dev->irq, &arcnet_interrupt, shared,
			"arcnet (COM20020)", dev)) {
		BUGMSG(D_NORMAL, "Can't get IRQ %d!\n", dev->irq);
		return -ENODEV;
	}*/

	if (dev->irq == 0)
     	return -EAGAIN;

	rt_stack_connect(dev, &STACK_manager);
	retval = rtdm_irq_request(&lp->irq_handle, dev->irq, 
arcnet_interrupt, 0,
                         "rt_arcnet", dev);
	if (retval)
     	return retval;

	rtdm_irq_enable(&lp->irq_handle);
	
	/*** RTnet ***/

	dev->base_addr = ioaddr;

	BUGMSG(D_NORMAL, "%s: station %02Xh found at %03lXh, IRQ %d.\n",
	       lp->card_name, dev->dev_addr[0], dev->base_addr, 
dev->irq);

	if (lp->backplane)
		BUGMSG(D_NORMAL, "Using backplane mode.\n");

	if (lp->timeout != 3)
		BUGMSG(D_NORMAL, "Using extended timeout value of %d.\n", 
lp->timeout);

	BUGMSG(D_NORMAL, "Using CKP %d - data rate %s.\n",
	       lp->setup >> 1,
	       clockrates[3 - ((lp->setup2 & 0xF0) >> 4) + ((lp->setup & 
0x0F) >> 1)]);

	/*** RTnet ***/

	/*if (register_netdev(dev)) {
		free_irq(dev->irq, dev);
		return -EIO;
	}*/
	
	if (rt_register_rtnetdev(dev))
     {
     	rtdm_irq_free(&lp->irq_handle);
     	return -EIO;
	}
		
	/*** RTnet ***/

	return 0;
}

3.) Ok. last question. It seems like I have a problem with module 
dependencies. The arcnet driver is set up to be loaded as four 
separate modules: arcnet.ko (the foundation), arc-rawmode.ko 
(provides rawmode encapsulation), com20020.ko (support for 
chipset), and com20020-pci.ko (support for pci-board).

I've done my homework and created four rt modules that compile and 
load into the kernel.. but the problem is that I cannot get them 
to load with 'rtnet start'. How do I specify dependencies in the 
'rtnet.conf' file? My dilemna is that if I specify com20020-pci 
without any extra work.. the program will not run because it 
cannot load the module without its dependencies.. BUT I cannot 
load rt_arcnet.ko and rt_com20020.ko before running 'rtnet start' 
because they both depend on the module rtnet!!

So I feel like I'm in a bit of a catch-22. Please tell me how to 
get around this problem.

Thank you so much for your help.

Chris Lightcap
University of Florida




On Tue Jul 11 04:03:33 EDT 2006, Jan Kiszka <jan...@we...> 
wrote:

> Chris Lightcap wrote:
>> Hello all,
>> 
>> I'd like to implement a real-time arcnet driver to communicate 
>> with
>> our mitsubishi PA-10 robot using RTAI and RTnet. I found in the
> 
> You are welcome!
> 
>> mailing list archive that there was some interest in this topic 
>> about
>> a year ago.
>> 
>> .. Has anyone made progress with a real-time arcnet driver? is it
> 
> I'm personally not aware of any effort.
> 
>> possible to simply modify the existing driver as explained in the
>> porting documentation? are there any additional problems I should
>> know of beforehand?
> 
> I think to remember once browsing through the Linux arcnet stack 
> without
> finding anything that's fundamentally different from the "normal"
> networking stack. So all the pattern of RTnet /should/ apply to 
> arcnet
> as well. If you encounter something that doesn't fit on first 
> sight,
> feel free to discuss it here.
> 
> Please build your port on top of latest RTnet and only use RTDM 
> for
> interfacing the real-time Linux services - this will help to 
> integrate
> your work into the official version later.
> 
> Jan
> 
> 



--
LIGHTCAP,CHRISTOPHER A

Re: [RTnet-developers] arcnet driver

[Jan K. <jan...@we...>]

Chris Lightcap wrote:
> Hello all,
>=20
> I'd like to implement a real-time arcnet driver to communicate with
> our mitsubishi PA-10 robot using RTAI and RTnet. I found in the

You are welcome!

> mailing list archive that there was some interest in this topic about
> a year ago.
>=20
> .. Has anyone made progress with a real-time arcnet driver? is it

I'm personally not aware of any effort.

> possible to simply modify the existing driver as explained in the
> porting documentation? are there any additional problems I should
> know of beforehand?

I think to remember once browsing through the Linux arcnet stack without
finding anything that's fundamentally different from the "normal"
networking stack. So all the pattern of RTnet /should/ apply to arcnet
as well. If you encounter something that doesn't fit on first sight,
feel free to discuss it here.

Please build your port on top of latest RTnet and only use RTDM for
interfacing the real-time Linux services - this will help to integrate
your work into the official version later.

Jan

[RTnet-developers] arcnet driver

[Chris L. <ca...@uf...>]

Hello all,

I'd like to implement a real-time arcnet driver to communicate with our =
mitsubishi PA-10 robot using RTAI and RTnet. I found in the mailing list =
archive that there was some interest in this topic about a year ago.

 .. Has anyone made progress with a real-time arcnet driver? is it =
possible to simply modify the existing driver as explained in the =
porting documentation? are there any additional problems I should know =
of beforehand?

Best regards,

Chris Lightcap
University of Florida

Re: [RTnet-developers] RTDM devices class and subclass

[Jan K. <jan...@we...>]

Marcelo Coelho wrote:
>> Definitely not. I was referring to the "rtnet" part - RTnet is only on=
e
>> RTDM user.
>=20
> Yes, but you're the only developer i can contact, and this is the less
> active mailling list...
>=20

I would prefer to see such a generic discussion on a generic mailing
list, like xenomai-core or rtai. There might be more people hanging
around, willing to contribute comments and ideas.

>=20
> Now about the driver, i searched in rtdm for something that could be
> related to the TTY associated structs and functions. Neither in the
> serial device nor in rtdm api, these functions are used. Is it possible=

> that you (the RTDM team) change that and start giving support for those=

> kind of devices in the same way the kernel does?

If this would be only about wrapping a *few* IOCTLs, I see no big
problems (except that the driver code may increase). What interfaces do
you have in mind?

Well, the termios interface as-is appeared to me as not well suited for
typical serial usage scenarios in hard-RT applications. Specifically,
the RTDM profile introduced an event concept and per-character
timestamping. As there were several extensions required anyway, I
consolidated the whole interface, making it more regular and targeted
with respect to UART devices - that's at least my feeling about it.

If your driver reveals some need to move common code into a high-level
serial layer anyway, adding a compat layer for certain IOCTLs the driver
does not need to know about might be an options. But note that, even
then, using tc*() functions will not work as they map to the Linux
ioctl() invocation, not the RTDM one.

Jan

Re: [RTnet-developers] RTDM devices class and subclass

[Marcelo C. <mjc...@cr...>]

> Definitely not. I was referring to the "rtnet" part - RTnet is only one
> RTDM user.

Yes, but you're the only developer i can contact, and this is the less
active mailling list...


Now about the driver, i searched in rtdm for something that could be
related to the TTY associated structs and functions. Neither in the
serial device nor in rtdm api, these functions are used. Is it possible
that you (the RTDM team) change that and start giving support for those
kind of devices in the same way the kernel does?

Thanks





DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software.

Re: [RTnet-developers] RTDM devices class and subclass

[Jan K. <jan...@we...>]

Marcelo Coelho wrote:
> Hi again,
>=20
>=20
>> Hmm, I wonder what made this message pop up on rtnet-devel. Nevermind.=
 :)
>=20
> Are you trying to say i'm not a developer?? :)

Definitely not. I was referring to the "rtnet" part - RTnet is only one
RTDM user.

>=20
>=20
>> PS: Submitting your driver for inclusion in RTAI and/or Xenomai may he=
lp
>> to accelerate the subclass reservation. ;)
>=20
> Don't worry that when i have something working, that could be usefull
> for other users, i'll send it over to you!
>=20

Looking forward!

Jan

Re: [RTnet-developers] RTDM devices class and subclass

[Marcelo C. <mjc...@cr...>]

Hi again,


> Hmm, I wonder what made this message pop up on rtnet-devel. Nevermind. :)

Are you trying to say i'm not a developer?? :)


> PS: Submitting your driver for inclusion in RTAI and/or Xenomai may help
> to accelerate the subclass reservation. ;)

Don't worry that when i have something working, that could be usefull
for other users, i'll send it over to you!




DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software.

Re: [RTnet-developers] RTDM devices class and subclass

[Jan K. <jan...@we...>]

Marcelo Coelho wrote:
> Hi Jan,
>=20

Hmm, I wonder what made this message pop up on rtnet-devel. Nevermind. :)=


>=20
> I've continuing the development of the serial device driver port to
> Real-Time. I've seen both Rtai_serial driver and the rtdm api and now i=

> think i'm starting to make some progress... :)
>=20
> Now i stumbled on detail that isn't referred on the RTDM api
> specification: There are some macros defining the Class and Subclass of=

> a RTDM driver. These regulations are defined by the rtdm team, right?=20

Yes, that's a rather loooong process. It involves issuing a formal
request for the number, a first review and rejection, a submission of a
revised request, a public hearing, several meetings of the steering
committee (at the expense of the requester, of course!), and then,
maybe, the granting.

> As i'm developing a serial device, my class and subclass should be
> RTDM_CLASS_SERIAL and RTDM_SUBCLASS_MOXA (for a Moxa RS-422 driver).
>=20

Ok, I take this question as step 1 and continue with step 2: The Moxa is
a specific chip with different features than a normal 16550A-compatible
UART? Will you implement less / more IOCTLs for this driver or some
other service differently? My point is that defining a subclass is only
required when the programming model differs.

Jan


PS: Submitting your driver for inclusion in RTAI and/or Xenomai may help
to accelerate the subclass reservation. ;)

[RTnet-developers] RTDM devices class and subclass

[Marcelo C. <mjc...@cr...>]

Hi Jan,


I've continuing the development of the serial device driver port to
Real-Time. I've seen both Rtai_serial driver and the rtdm api and now i
think i'm starting to make some progress... :)

Now i stumbled on detail that isn't referred on the RTDM api
specification: There are some macros defining the Class and Subclass of
a RTDM driver. These regulations are defined by the rtdm team, right? 
As i'm developing a serial device, my class and subclass should be
RTDM_CLASS_SERIAL and RTDM_SUBCLASS_MOXA (for a Moxa RS-422 driver).


Thanks for the help





DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software.

Re: [RTnet-developers] Another try... Patch to support routing

[M. K. <mat...@ar...>]

Hi Jan,

I have tested the version that is now in subversion and this is working fin=
e. Thanks.

Regards

Mathias



> Jan Kiszka wrote:
> > M. Koehrer wrote:
> >> Hi Jan,
> >>
> >> enclosed is another patch the supports the rtnet routing considering t=
he
> IP source address.
> >> I have a used a couple of #ifdefs to switch between the standard and t=
he
> "new" behaviour.
> >> This seems to me clearer than using macros (to my opinion macros can b=
e
> extremely confusing...).
> >=20
> > Really a matter of taste. The macro-way reduces the number of #ifdefs t=
o
> > two occurrences: the prototype and the function definition. Granted, we
> > only have a few invocations here, but even those few places suffer with
> > respect to readability in my eyes.
> >=20
> >> I have now also extended the rtroute del command to support a device
> there.
> >=20
> > Ok, will see how to merge this and give feedback on the result then.
> >=20
>=20
> Done. Please test it and report if works as it should.
>=20
> Jan
>=20
>=20

--=20
Mathias Koehrer
mat...@ar...


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: g=FCnsti=
g
und schnell mit DSL - das All-Inclusive-Paket f=FCr clevere Doppel-Sparer,
nur  44,85 =80  inkl. DSL- und ISDN-Grundgeb=FChr!
http://www.arcor.de/rd/emf-dsl-2

Re: [RTnet-developers] Re: Another try... Patch to support routing using also the IP source address

[Jan K. <jan...@we...>]

Jan Kiszka wrote:
> M. Koehrer wrote:
>> Hi Jan,
>>
>> enclosed is another patch the supports the rtnet routing considering t=
he IP source address.
>> I have a used a couple of #ifdefs to switch between the standard and t=
he "new" behaviour.
>> This seems to me clearer than using macros (to my opinion macros can b=
e extremely confusing...).
>=20
> Really a matter of taste. The macro-way reduces the number of #ifdefs t=
o
> two occurrences: the prototype and the function definition. Granted, we=

> only have a few invocations here, but even those few places suffer with=

> respect to readability in my eyes.
>=20
>> I have now also extended the rtroute del command to support a device t=
here.
>=20
> Ok, will see how to merge this and give feedback on the result then.
>=20

Done. Please test it and report if works as it should.

Jan

[RTnet-developers] Re: Another try... Patch to support routing using also the IP source address

[Jan K. <jan...@we...>]

M. Koehrer wrote:
> Hi Jan,
>=20
> enclosed is another patch the supports the rtnet routing considering th=
e IP source address.
> I have a used a couple of #ifdefs to switch between the standard and th=
e "new" behaviour.
> This seems to me clearer than using macros (to my opinion macros can be=
 extremely confusing...).

Really a matter of taste. The macro-way reduces the number of #ifdefs to
two occurrences: the prototype and the function definition. Granted, we
only have a few invocations here, but even those few places suffer with
respect to readability in my eyes.

> I have now also extended the rtroute del command to support a device th=
ere.

Ok, will see how to merge this and give feedback on the result then.

Thanks for the patch,

Jan

[RTnet-developers] Re: [RTnet-users] intel e1000 driver

[Jan K. <jan...@we...>]

R. Tai wrote:
> Hi folks,
>=20
> just popped in to rtnet - great! Even if I just need parts, everything
> is in place and worked with my first attempt.

Good to hear, especially that Murphy is not everywhere. ;)

>=20
> BTW: does somebody work on the intel e1000 driver? If so, please let me=

> know how I can help.

At least I'm not aware of any activity.

>=20
> Cheers,
>  Roman
>=20
> PS: Sorry for cross-posting (is that thread specific to devel or users?=
)

Well, if you want to actively work on this, the devel list is the right
place for discussion...

Jan

[RTnet-developers] intel e1000 driver

[R. T. <rt...@x-...>]

Hi folks,

just popped in to rtnet - great! Even if I just need parts, everything 
is in place and worked with my first attempt.

BTW: does somebody work on the intel e1000 driver? If so, please let me 
know how I can help.

Cheers,
  Roman

PS: Sorry for cross-posting (is that thread specific to devel or users?)

[RTnet-developers] Trying to fix bug in RTNET v0.7

[<alk...@ot...>]

Hello again, 
I am trying to trace the root-cause of a failure to execute
"callback_func(rt_socket_context(sock), callback_arg);"
source file: af_packet.c 
RTNET v0.7

Through the use of my solution/tool I am working on, and some debug
messages, I have reached the conclusion that this only happens when
"ifindex != 0" and as a result the socketbuffer memory is de-allocated
(kfree_rtskb(skb)). 

callback_func fails to execute because ifindex seems not to have been
initialized and prints a random value. 
Now this means that in ifindex=sock->prot.packet.ifindex,
sock->prot.packet.ifindex is not initialized either, maybe due to the
uncommon (hardcore would be more precise) way of typecasting
"rtpacket_type pt" and initializing "sock"...here take a look:

struct rtsocket *sock = (struct rtsocket *)(((u8 *)pt) - 
((u8 *)&(struct rtsocket *)0)->prot.socket));

and it all comes down to "pt"...what goes so wrong with "pt" to
(indirectly)contain a non-initialized pointer to ifindex???

Thank you even reading through this mumbo-jumbo!

[RTnet-developers] powerlink

[s.a. <san...@fr...>]

Hi,

I am looking for documents describing the way powerlink is working (data
link layer) .
Where to find it ????

Best Regards
Steph

Re: [RTnet-developers] Help on compiling and debugging

[Jan K. <jan...@we...>]

Marcelo Coelho wrote:
> Hi!
>=20
> As the subject states, i'm having some problems in compiling and
> diagnosing programming errors. What tools do you use? How can i

Tools for compiling? gcc ;) (personally, I'm not using an IDE, if this
is what you mean)

For diagnosing, there is essentially the way to instrument the code with
[rtdm_]printk, RTNET_ASSERT, or also the new Adeos/Ipipe-tracing
mechanism (this can be used to generate function call histories on
specific events). We are unfortunately still lacking a Ipipi-aware
kernel debugger.

A useful hint is to run the fresh code on a dedicated system to avoid
having to reboot your development box after each potential crash. We
have a small specialised distribution here which incorporates RTnet in
its build and install process.

> incorporate my code within rtnet?

Regarding code incorporation: extend the existing GNUmakefile.am with
your source file(s) and re-run scripts/autogen.sh (autotools have to be
installed).

>=20
>=20
> Thanks
>=20
>=20
> P.S.: Jan, as you're the only one responding to e-mails, are you the
> only one programming rtnet?
>=20

I'm the fastest at the reply button ;). There is more than a single
RTnet developer (Wolfgang, e.g., is working on the PowerPC world). They
contribute on an irregular basis when time permits or someone pays for it=
=2E

Jan