Re: [RTnet-developers] arcnet driver
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
Re: [RTnet-developers] arcnet driver
|
From: Chris L. <ca...@uf...> - 2006-07-14 16:16:41
|
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
>
>
|
