RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

Baseline

Browse Source
This commit is contained in:
Joel Sherrill
1998-08-19 20:29:35 +00:00
parent 26b5c77fb1
commit ab0c6890bf
9 changed files with 2321 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
doc/networking/Makefile Normal file
View File

@@ -0,0 +1,82 @@
#
# COPYRIGHT (c) 1988-1998.
# On-Line Applications Research Corporation (OAR).
# All rights reserved.
#
# $Id$
#
PROJECT=networking
DISTRIBUTION_LEVEL=public
include ../Make.config
REPLACE=../tools/word-replace
all: html info ps
dirs:
$(make-dirs)
COMMON_FILES=../common/cpright.texi ../common/setup.texi
GENERATED_FILES=networkapp.texi driver.texi networktasks.texi testing.texi
FILES= $(PROJECT).texi \
networktasks.texi preface.texi $(GENERATED_FILES)
INFOFILES=$(wildcard $(PROJECT) $(PROJECT)-*)
info: dirs networking
#cp $(wildcard $(PROJECT) $(PROJECT)-*) $(INFO_INSTALL)
cp $(PROJECT) $(INFO_INSTALL)
networking: $(FILES)
$(MAKEINFO) $(PROJECT).texi
dvi: $(PROJECT).dvi
ps: dirs $(PROJECT).ps
$(PROJECT).ps: $(PROJECT).dvi
dvips -o $(PROJECT).ps $(PROJECT).dvi
cp $(PROJECT).ps $(PS_INSTALL)
$(PROJECT).dvi: $(FILES)
$(TEXI2DVI) $(PROJECT).texi
networktasks.texi: networktasks.t
$(BMENU) -p "Preface" \
-u "Top" \
-n "Writing RTEMS/KA9Q Network Device Drivers" ${*}.t
driver.texi: driver.t
$(BMENU) -p "KA9Q Task Structure and Data Flow" \
-u "Top" \
-n "Using KA9Q networking in an RTEMS Application" ${*}.t
networkapp.texi: networkapp.t
$(BMENU) -p "Writing RTEMS/KA9Q Network Device Drivers Write your driver show function" \
-u "Top" \
-n "Testing the Driver" ${*}.t
testing.texi: testing.t
$(BMENU) -p "Using KA9Q networking in an RTEMS Application Domain Name Service" \
-u "Top" \
-n "Command and Variable Index" ${*}.t
html: dirs $(FILES)
-mkdir -p $(WWW_INSTALL)/networking
rm -f $(WWW_INSTALL)/$(PROJECT)/networking.gif
cp networking.gif $(WWW_INSTALL)/$(PROJECT)/networking.gif
$(TEXI2WWW) $(TEXI2WWW_ARGS) -dir $(WWW_INSTALL)/$(PROJECT) \
$(PROJECT).texi
clean:
rm -f *.o $(PROG) *.txt core
rm -f *.dvi *.ps *.log *.aux *.cp *.fn *.ky *.pg *.toc *.tp *.vr $(BASE)
rm -f $(PROJECT) $(PROJECT)-* $(GENERATED_FILES)
rm -f networking networking-*
rm -f timedata.texi timetbl.texi intr.texi wksheets.texi
rm -f timetbl.t wksheets.t
rm -f *.fixed _*

281
doc/networking/driver.t Normal file
View File

@@ -0,0 +1,281 @@
@c
@c Written by Eric Norum
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter Writing RTEMS Network Device Drivers
@section Introduction
This chapter is intended to provide an introduction to the
procedure for writing RTEMS network device drivers.
The example code is taken from the `Generic 68360' network device
driver. The source code for this driver is located in the
@code{c/src/lib/libbsp/m68k/gen68360/network} directory in the RTEMS
source code distribution. You should have a copy of this driver at
hand when reading the following notes.
@section Learn about the network device
Before starting to write the network driver you need to be completely
familiar with the programmer's view of the device.
The following points list some of the details of the
device that must be understood before a driver can be written.
@itemize @bullet
@item Does the device use DMA to transfer packets to and from
memory or does the processor have to
copy packets to and from memory on the device?
@item If the device uses DMA, is it capable of forming a single
outtoing packet from multiple fragments scattered in separate
memory buffers?
@item If the device uses DMA, is it capable of chaining multiple
outgoing packets, or does each outgoing packet require
intervention by the driver?
@item Does the device automatically pad short frames to the minimum
64 bytes or does the driver have to supply the padding?
@item Does the device automatically retry a transmission on detection
of a collision?
@item If the device uses DMA, is it capable of buffering multiple
packets to memory, or does the receiver have to be restarted
after the arrival of each packet?
@item How are packets that are too short, too long, or received with
CRC errors handled? Does the device automatically continue
reception or does the driver have to intervene?
@item How is the device Ethernet address set? How is the device
programmed to accept or reject broadcast and multicast packets?
@item What interrupts does the device generate? Does it generate an
interrupt for each incoming packet, or only for packets received
without error? Does it generate an interrupt for each packet
transmitted, or only when the transmit queue is empty? What
happens when a transmit error is detected?
@end itemize
In addition, some controllers have specific questions regarding
board specific configuration. For example, the SONIC Ethernet
controller has a very configurable data bus interface. It can
even be configured for sixteen and thirty-two bit data buses. This
type of information should be obtained from the board vendor.
@section Understand the network scheduling conventions
When writing code for your driver transmit and receive tasks you must
take care to follow the network scheduling conventions. All tasks
which are associated with networking share various
data structures and resources. To ensure the consistency
of these structures the tasks
execute only when they hold the network semaphore (@code{rtems_bsdnet_semaphore}).
Your transmit and receive tasks must abide by this protocol which means you must
be careful to avoid `deadly embraces' with the other network tasks.
A number of routines are provided to make it easier for your code
to conform to the network task scheduling conventions.
@itemize @bullet
@item @code{void rtems_bsdnet_semaphore_release(void)}
This function releases the network semaphore.
Your task must call this function immediately before
making any blocking RTEMS request.
@item @code{void rtems_bsdnet_semaphore_obtain(void)}
This function obtains the network semaphore.
If your task has released the network semaphore to allow other
network-related tasks to run while your task blocks you must call this
function to reobtain the semaphore immediately after the return from the
blocking RTEMS request.
@item @code{rtems_bsdnet_event_receive(rtems_event_set, rtems_option, rtems_interval, rtems_event_set *)}
Your task should call this function when it wishes to wait for an event.
This function releases the network semaphore,
calls @code{rtems_event_receive} to wait for the specified event
or events and reobtains the semaphore.
The value returned is the value returned by the @code{rtems_event_receive}.
@end itemize
@section Write your driver attach function
The driver attach function is responsible for configuring the driver
and making the connection between the network stack
and the driver.
Driver attach functions take a pointer to an
@code{rtems_bsdnet_ifconfig} structure as their only argument.
and set the driver parameters based on the
values in this structure. If an entry in the configuration
structure is zero the attach function chooses an
appropriate default value for that parameter.
The driver should then set up several fields in the ifnet structure
in the device-dependent data structure supplied and maintained by the driver:
@table @code
@item ifp->if_softc
Pointer to the device-dependent data. The first entry
in the device-dependent data structure must be an @code{arpcom}
structure.
@item ifp->if_name
The name of the device. The network stack uses this string
and the device number for device name lookups.
@item ifp->if_unit
The device number. The network stack uses this number and the
device name for device name lookups. For example, if
@code{ifp->if_name} is @samp{scc}, and @code{ifp->if_unit} is @samp{1},
the full device name would be @samp{scc1}.
@item ifp->if_mtu
The maximum transmission unit for the device. For Ethernet
devices this value should almost always be 1500.
@item ifp->if_flags
The device flags. Ethernet devices should set the flags
to @code{IFF_BROADCAST|IFF_SIMPLEX}, indicating that the
device can broadcast packets to multiple destinations
and does not receive and transmit at the same time.
@item ifp->if_snd.ifq_maxlen
The maximum length of the queue of packets waiting to be
sent to the driver. This is normally set to @code{ifqmaxlen}.
@item ifp->if_init
The address of the driver initialization function.
@item ifp->if_start
The address of the driver start function.
@item ifp->if_ioctl
The address of the driver ioctl function.
@item ifp->if_output
The address of the output function. Ethernet devices
should set this to @code{ether_output}.
@end table
Once the attach function has set up the above entries it must link the
driver data structure onto the list of devices by
calling @code{if_attach}. Ethernet devices should then
call @code{ether_ifattach}. Both functions take a pointer to the
device's @code{ifnet} structure as their only argument.
The attach function should return a non-zero value to indicate that
the driver has been successfully configured and attached.
@section Write your driver start function.
This function is called each time the network stack wants to start the
transmitter. This occures whenever the network stack adds a packet
to a device's send queue and the @code{IFF_OACTIVE} bit in the
device's @code{if_flags} is not set.
For many devices this function need only set the @code{IFF_OACTIVE} bit in the
@code{if_flags} and send an event to the transmit task
indicating that a packet is in the driver transmit queue.
@section Write your driver initialization function.
This function should initialize the device, attach to interrupt handler,
and start the driver transmit and receive tasks. The function
@example
rtems_id
rtems_bsdnet_newproc (char *name,
int stacksize,
void(*entry)(void *),
void *arg);
@end example
should be used to start the driver tasks.
Note that the network stack may call the driver initialization function more
than once.
Make sure you don't start multiple versions of the receive and transmit tasks.
@section Write your driver transmit task.
This task is reponsible for removing packets from the driver send queue and sending them to the device. The task should block waiting for an event from the
driver start function indicating that packets are waiting to be transmitted.
When the transmit task has drained the driver send queue the task should clear
the @code{IFF_OACTIVE} bit in @code{if_flags} and block until another outgoing
packet is queued.
@section Write your driver receive task.
This task should block until a packet arrives from the device. If the
device is an Ethernet interface the function @code{ether_input} should be called
to forward the packet to the network stack. The arguments to @code{ether_input}
are a pointer to the interface data structure, a pointer to the ethernet
header and a pointer to an mbuf containing the packet itself.
@section Write your driver interrupt handler.
A typical interrupt handler will do nothing more than the hardware
manipulation required to acknowledge the interrupt and send an RTEMS event
to wake up the driver receive or transmit task waiting for the event.
Network interface interrupt handlers must not make any calls to other
network routines.
@section Write your driver ioctl function.
This function handles ioctl requests directed at the device. The ioctl
commands which must be handled are:
@table @code
@item SIOCGIFADDR
@item SIOCSIFADDR
If the device is an Ethernet interface these
commands should be passed on to @code{ether_ioctl}.
@item SIOCSIFFLAGS
This command should be used to start or stop the device,
depending on the state of the interface @code{IFF_UP} and
@code{IFF_RUNNING} bits in @code{if_flags}:
@table @code
@item IFF_RUNNING
Stop the device.
@item IFF_UP
Start the device.
@item IFF_UP|IFF_RUNNING
Stop then start the device.
@item 0
Do nothing.
@end table
@end table
@section Write your driver statistic-printing function
This function should print the values of any statistic/diagnostic
counters your driver may use. The driver ioctl function should call
the statistic-printing function when the ioctl command is
@code{SIO_RTEMS_SHOW_STATS}.

107
doc/networking/network.texi Normal file
View File

@@ -0,0 +1,107 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename ka9q
@syncodeindex vr fn
@synindex ky cp
@paragraphindent 0
@c @smallbook
@c %**end of header
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@c
@c Master file for the network Supplement
@c
@include ../common/setup.texi
@ignore
@ifinfo
@format
START-INFO-DIR-ENTRY
* RTEMS Network Supplement:
END-INFO-DIR-ENTRY
@end format
@end ifinfo
@end ignore
@c
@c Title Page Stuff
@c
@set edition @value{RTEMS-EDITION}
@set version @value{RTEMS-VERSION}
@set update-date @value{RTEMS-UPDATE-DATE}
@set update-month @value{RTEMS-UPDATE-MONTH}
@c
@c I don't really like having a short title page. --joel
@c
@c @shorttitlepage RTEMS Network Supplement
@setchapternewpage odd
@settitle RTEMS Network Supplement
@titlepage
@finalout
@title RTEMS Network Supplement
@subtitle Edition @value{edition}, for RTEMS @value{version}
@sp 1
@subtitle @value{update-month}
@author On-Line Applications Research Corporation
@page
@include ../common/cpright.texi
@end titlepage
@c This prevents a black box from being printed on "overflow" lines.
@c The alternative is to rework a sentence to avoid this problem.
@include preface.t
@include networktasks.t
@include driver.t
@include networkapp.t
@c@include testing.texi
@ifinfo
@node Top, Preface, (dir), (dir)
@top ka9q
This is the online version of the RTEMS Network Supplement.
@menu
* Preface::
* Network Task Structure and Data Flow::
* Writing RTEMS Network Device Drivers::
* Using Networking in an RTEMS Application::
* Testing the Driver::
* Command and Variable Index::
* Concept Index::
@end menu
@end ifinfo
@c
@c
@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
@c
@node Command and Variable Index, Concept Index, Testing the Driver Throughput, Top
@unnumbered Command and Variable Index
There are currently no Command and Variable Index entries.
@c @printindex fn
@node Concept Index, , Command and Variable Index, Top
@unnumbered Concept Index
There are currently no Concept Index entries.
@c @printindex cp
@c @contents
@bye

250
doc/networking/networkapp.t Normal file
View File

@@ -0,0 +1,250 @@
@c
@c Written by Eric Norum
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter Using networking in an RTEMS application
@section Makefile changes
@subsection Including the required managers
The KA9Q networking code requires several RTEMS managers
in the application:
@example
MANAGERS = io event semaphore
@end example
@subsection Increasing the size of the heap
The networking tasks allocate a lot of memory. For most applications
the heap should be at least 256 kbytes.
The amount of memory set aside for the heap can be adjusted by setting
the @code{CFLAGS_LD} definition as shown below:
@example
CFLAGS_LD += -Wl,--defsym -Wl,HeapSize=0x80000
@end example
This sets aside 512 kbytes of memory for the heap.
@section System Configuration
The networking tasks allocate some RTEMS objects. These
must be accounted for in the application configuration table. The following
lists the requirements.
@table @b
@item TASKS
One network task plus a receive and transmit task for each device.
@item SEMAPHORES
One network semaphore plus one syslog mutex semaphore if the application uses
openlog/syslog.
@item EVENTS
The network stack uses @code{RTEMS_EVENT_24} and @code{RTEMS_EVENT_25}.
This has no effect on the application configuration, but
application tasks which call the network functions should not
use these events for other purposes.
@end table
@section Initialization
@subsection Additional include files
The source file which declares the network configuration
structures and calls the network initialization function must include
@example
#include <rtems_bsdnet.h>
@end example
@subsection Network configuration
The network configuration is specified by declaring
and initializing the @code{rtems_bsdnet_configuration}
structure. This structure may be declared @code{const} since the
network initialization functions do not write to any of the entries.
The structure entries are described in the following table.
If your application uses BOOTP to obtain network configuration
information and if you are happy with the default values described
below, you need to provide only the first two entries in this structure.
@table @code
@item struct rtems_bsdnet_ifconfig *ifconfig
A pointer to the first configuration structure of the first network
device. This structure is described in the following section.
You must provide a value for this entry since there is no default value for it.
@item void (*bootp)(void)
This entry should be set to @code{rtems_bsdnet_do_bootp}
if your application will use BOOTP to obtain network configuration information.
It should be set to @code{NULL}
if your application does not use BOOTP.
@item int network_task_priority
The priority at which the network task and network device
receive and transmit tasks will run.
If a value of 0 is specified the tasks will run at priority 100.
@item unsigned long mbuf_bytecount
The number of bytes to allocate from the heap for use as mbufs.
If a value of 0 is specified, 64 kbytes will be allocated.
@item unsigned long mbuf_cluster_bytecount
The number of bytes to allocate from the heap for use as mbuf clusters.
If a value of 0 is specified, 128 kbytes will be allocated.
@item char *hostname
The host name of the system.
If this entry is @code{NULL} the host name,
and all the remaining values specified by the @code{rtems_bsdnet_configuration}
structure will be obtained from a BOOTP server.
@item char *domainname
The name of the Internet domain to which the system belongs.
@item char *gateway
The Internet host number of the network gateway machine,
specified in `dotted decimal' (@code{129.128.4.1}) form.
@item char *log_host
The Internet host number of the machine to which @code{syslog} messages
will be sent.
@item char *name_server
The Internet host number of up to three machines to be used as
Internet Domain Name Servers.
@end table
@example
rtems_task_set_priority (RTEMS_SELF, 30, &oldPri);
@end example
@subsection Network device configuration
Network devices are specified and configured by declaring and initializing a
@code{struct rtems_bsdnet_ifcontig} structure for each network device.
These structures may be declared @code{const} since the
network initialization functions do not write to any of the entries.
The structure entries are described in the following table. An application
which uses a single network interface, gets network configuration information
from a BOOTP server, and uses the default values for all driver
parameters needs to initialize only the first two entries in the
structure.
@table @code
@item char *name
The full name of the network device. This name consists of the
driver name and the unit number (e.g. @code{"scc1"}).
@item int (*attach)(struct rtems_bsdnet_ifconfig *conf)
The address of the driver @code{attach} function. The network
initialization function calls this function to configure the driver and
attach it to the network stack.
@item struct rtems_bsdnet_ifconfig *next
A pointer to the network device configuration structure for the next network
interface, or @code{NULL} if this is the configuration structure of the
last network interface.
@item char *ip_address
The Internet address of the device,
specified in `dotted decimal' (@code{129.128.4.2}) form, or @code{NULL}
if the device configuration information is being obtained from a
BOOTP server.
@item char *ip_netmask
The Internet inetwork mask of the device,
specified in `dotted decimal' (@code{255.255.255.0}) form, or @code{NULL}
if the device configuration information is being obtained from a
BOOTP server.
@item void *hardware_address
The hardware address of the device, or @code{NULL} if the driver is
to obtain the hardware address in some other way (usually by reading
it from the device or from the bootstrap ROM).
@item int ignore_broadcast
Zero if the device is to accept broadcast packets, non-zero if the device
is to ignore broadcast packets.
@item int mtu
The maximum transmission unit of the device, or zero if the driver
is to choose a default value (typically 1500 for Ethernet devices).
@item int rbuf_count
The number of receive buffers to use, or zero if the driver is to
choose a default value
@item int xbuf_count
The number of transmit buffers to use, or zero if the driver is to
choose a default value
Keep in mind that some network devices may use 4 or more
transmit descriptors for a single transmit buffer.
@end table
@subsection Network initialization
The networking tasks must be started before any
network I/O operations can be performed. This is done by calling:
@example
rtems_bsdnet_initialize_network ();
@end example
@section Application code
The RTEMS network package provides almost a complete set of BSD network
services. The network functions work like their BSD counterparts
with the following exceptions:
@itemize
@item A given socket can be read or written by only one task at a time.
@item There is no @code{select} function.
@item You must call @code{openlog} before calling any of the @code{syslog} functions.
@item @b{Some of the network functions are not thread-safe.}
For example the following functions return a pointer to a static
buffer which remains valid only until the next call:
@table @code
@item gethostbyaddr
@item gethostbyname
@item inet_ntoa
(@code{inet_ntop} is thread-safe, though).
@end table
@end itemize
@subsection Network statistics
There are a number of functions to print statistics gathered by the network stack:
@table @code
@item rtems_bsdnet_show_if_stats
Display statistics gathered by network interfaces.
@item rtems_bsdnet_show_ip_stats
Display IP packet statistics.
@item rtems_bsdnet_show_icmp_stats
Display ICMP packet statistics.
@item rtems_bsdnet_show_tcp_stats
Display TCP packet statistics.
@item rtems_bsdnet_show_udp_stats
Display UDP packet statistics.
@item rtems_bsdnet_show_mbuf_stats
Display mbuf statistics.
@item rtems_bsdnet_show_inet_routes
Display the routing table.
@end table

1343
doc/networking/networking.eps Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
doc/networking/networking.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.1 KiB

60
doc/networking/networktasks.t Normal file
View File

@@ -0,0 +1,60 @@
@c
@c Written by Eric Norum
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter Network Task Structure and Data Flow
A schematic diagram of the tasks and message @b{mbuf} queues in a
simple RTEMS networking application is shown in the following
figure:
@ifset use-ascii
@example
@group
NO ASCII VERSION OF THE TASKING FIGURE IS AVAILABLE
@end group
@end example
@end ifset
@ifset use-tex
@c for now use the ascii version
@example
@group
NO TEX VERSION OF THE TASKING FIGURE IS AVAILABLE
@end group
@end example
@end ifset
@ifset use-html
@html
<IMG SRC="networking.gif" ALIGN=CENTER
ALT="Network Task Structure and Data Flow">
@end html
@end ifset
The transmit task for each network interface is normally blocked waiting
for a packet to arrive in the transmit queue. Once a packet arrives, the
transmit task may block waiting for an event from the transmit interrupt
handler. The transmit interrupt handler sends an RTEMS event to the transmit
task to indicate that transmit hardware resources have become available.
The receive task for each network interface is normally blocked waiting
for an event from the receive interrupt handler. When this event is received
the receive task reads the packet and forwards it to the network stack
for subsequent processing by the network task.
The network task processes incoming packets and takes care of
timed operations such as handling TCP timeouts and
aging and removing routing table entries.
The `Network code' contains routines which may run in the context of
the user application tasks, the interface receive task or the network task.
A network semaphore ensures that
the data structures manipulated by the network code remain consistent.

23
doc/networking/preface.t Normal file
View File

@@ -0,0 +1,23 @@
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@ifinfo
@node Preface, Network Task Structure and Data Flow, Top, Top
@end ifinfo
@unnumbered Preface
This document describes the RTEMS specific parts of the FreeBSD TCP/IP
stack. Much of this documentation was written by Eric Norum
@ifset use-html
(@href{eric@@skatter.usask.ca,,,mailto:eric@@skatter.usask.ca})
@end ifset
@ifclear use-html
(eric@@skatter.usask.ca)
@end ifclear
of the Saskatchewan Accelerator Laboratory
who also ported the FreeBSD TCP/IP stack to RTEMS.

175
doc/networking/testing.t Normal file
View File

@@ -0,0 +1,175 @@
@c
@c Written by Eric Norum
@c
@c COPYRIGHT (c) 1988-1998.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter Testing the Driver
@section Preliminary Setup
The network used to test the driver should include at least:
@itemize @bullet
@item The hardware on which the driver is to run.
It makes testing much easier if you can run a debugger to control
the operation of the target machine.
@item An Ethernet network analyzer or a workstation with an
`Ethernet snoop' program such as @code{ethersnoop} or
@code{tcpdump}.
@item A workstation.
@end itemize
During early debug, you should consider putting the target, workstation,
and snooper on a small network by themselves. This offers a few
advantages:
@itemize @bullet
@item There is less traffic to look at on the snooper and for the target
to process while bringing the driver up.
@item Any serious errors will impact only your small network not a building
or campus network. You want to avoid causing any unnecessary problems.
@item Test traffic is easier to repeatably generate.
@item Performance measurements are not impacted by other systems on
the network.
@end itemize
@section Driver basic operation
The network demonstration program @code{netdemo} may be used for these tests.
@itemize @bullet
@item Edit @code{networkconfig.h} to reflect the values for your network.
@item Start with @code{RTEMS_USE_BOOTP} not defined.
@item Edit @code{networkconfig.h} to configure the driver
with an
explicit Ethernet and Internet address and with reception of
broadcast packets disabled:
Verify that the program continues to run once the driver has been attached.
@item Issue a @samp{u} command to send UDP
packets to the `discard' port.
Verify that the packets appear on the network.
@item Issue a @samp{s} command to print the network and driver statistics.
@item On a workstation, add a static route to the target system.
@item On that same workstation try to `ping' the target system.
Verify that the ICMP echo request and reply packets appear on the net.
@item Remove the static route to the target system.
Modify @code{networkconfig.h} to attach the driver
with reception of broadcast packets enabled.
Try to `ping' the target system again.
Verify that ARP request/reply and ICMP echo request/reply packets appear
on the net.
@item Issue a @samp{t} command to send TCP
packets to the `discard' port.
Verify that the packets appear on the network.
@item Issue a @samp{s} command to print the network and driver statistics.
@item Verify that you can telnet to ports 24742
and 24743 on the target system from one or more
workstations on your network.
@end itemize
@section BOOTP operation
Set up a BOOTP server on the network.
Set define @code{RTEMS USE_BOOT} in @code{networkconfig.h}.
Run the @code{netdemo} test program.
Verify that the target system configures itself from the BOOTP server and
that all the above tests succeed.
@section Stress Tests
Once the driver passes the tests described in the previous section it should
be subjected to conditions which exercise it more
thoroughly and which test its error handling routines.
@subsection Giant packets
@itemize @bullet
@item Recompile the driver with @code{MAXIMUM_FRAME_SIZE} set to
a smaller value, say 514.
@item `Ping' the driver from another workstation and verify
that frames larger than 514 bytes are correctly rejected.
@item Recompile the driver with @code{MAXIMUM_FRAME_SIZE} restored to 1518.
@end itemize
@subsection Resource Exhaustion
@itemize @bullet
@item Edit @code{networkconfig.h}
so that the driver is configured with just two receive and transmit descriptors.
@item Compile and run the @code{netdemo} program.
@item Verify that the program operates properly and that you can
still telnet to both the ports.
@item Display the driver statistics (Console `@code{s}' command or telnet
`control-G' character) and verify that:
@enumerate
@item The number of transmit interrupts is non-zero.
This indicates that all transmit descriptors have been in use at some time.
@item The number of missed packets is non-zero.
This indicates that all receive descriptors have been in use at some time.
@end enumerate
@end itemize
@subsection Cable Faults
@itemize @bullet
@item Run the @code{netdemo} program.
@item Issue a `@code{u}' console command to make the target machine transmit
a bunch of UDP packets.
@item While the packets are being transmitted, disconnect and reconnect the
network cable.
@item Display the network statistics and verify that the driver has
detected the loss of carrier.
@item Verify that you can still telnet to both ports on the target machine.
@end itemize
@subsection Throughput
Run the @code{ttcp} network benchmark program.
Transfer large amounts of data (100's of megabytes) to and from the target
system.