From 23a5ce44981ae3c5d92885ac089b2be825d2550e Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Sat, 29 Oct 2016 05:09:35 +1100 Subject: Remove the old files. --- networking/networking_old_reference_only.rst | 2044 -------------------------- 1 file changed, 2044 deletions(-) delete mode 100644 networking/networking_old_reference_only.rst (limited to 'networking/networking_old_reference_only.rst') diff --git a/networking/networking_old_reference_only.rst b/networking/networking_old_reference_only.rst deleted file mode 100644 index ad8f9c0..0000000 --- a/networking/networking_old_reference_only.rst +++ /dev/null @@ -1,2044 +0,0 @@ -.. comment SPDX-License-Identifier: CC-BY-SA-4.0 - -:orphan: - - - -.. COMMENT: %**end of header - -.. COMMENT: COPYRIGHT (c) 1989-2013. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -.. COMMENT: Master file for the network Supplement - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -.. COMMENT: The following determines which set of the tables and figures we will use. - -.. COMMENT: We default to ASCII but if available TeX or HTML versions will - -.. COMMENT: be used instead. - -.. COMMENT: @clear use-html - -.. COMMENT: @clear use-tex - -.. COMMENT: The following variable says to use texinfo or html for the two column - -.. COMMENT: texinfo tables. For somethings the format does not look good in html. - -.. COMMENT: With our adjustment to the left column in TeX, it nearly always looks - -.. COMMENT: good printed. - -.. COMMENT: Custom whitespace adjustments. We could fiddle a bit more. - -.. COMMENT: Title Page Stuff - -.. COMMENT: I don't really like having a short title page. -joel - -.. COMMENT: @shorttitlepage RTEMS Network Supplement - -======================== -RTEMS Network Supplement -======================== - -.. COMMENT: COPYRIGHT (c) 1988-2015. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -.. COMMENT: The following puts a space somewhere on an otherwise empty page so we - -.. COMMENT: can force the copyright description onto a left hand page. - -COPYRIGHT © 1988 - 2015. - -On-Line Applications Research Corporation (OAR). - -The authors have used their best efforts in preparing -this material. These efforts include the development, research, -and testing of the theories and programs to determine their -effectiveness. No warranty of any kind, expressed or implied, -with regard to the software or the material contained in this -document is provided. No liability arising out of the -application or use of any product described in this document is -assumed. The authors reserve the right to revise this material -and to make changes from time to time in the content hereof -without obligation to notify anyone of such revision or changes. - -The RTEMS Project is hosted at http://www.rtems.org. Any -inquiries concerning RTEMS, its related support components, or its -documentation should be directed to the Community Project hosted athttp://www.rtems.org. - -Any inquiries for commercial services including training, support, custom -development, application development assistance should be directed tohttp://www.rtems.com. - -.. COMMENT: This prevents a black box from being printed on "overflow" lines. - -.. COMMENT: The alternative is to rework a sentence to avoid this problem. - -RTEMS TCP/IP Networking Supplement -################################## - -.. COMMENT: COPYRIGHT (c) 1989-2011. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Preface -####### - -This document describes the RTEMS specific parts of the FreeBSD TCP/IP -stack. Much of this documentation was written by Eric Norum -(eric@skatter.usask.ca) -of the Saskatchewan Accelerator Laboratory -who also ported the FreeBSD TCP/IP stack to RTEMS. - -The following is a list of resources which should be useful in trying -to understand Ethernet: - -- *Charles Spurgeon’s Ethernet Web Site* - "This site provides extensive information about Ethernet - (IEEE 802.3) local area network (LAN) technology. Including - the original 10 Megabit per second (Mbps) system, the 100 Mbps - Fast Ethernet system (802.3u), and the Gigabit Ethernet system (802.3z)." - The URL is: - (http://www.ethermanage.com/ethernet/ethernet.html) - -- *TCP/IP Illustrated, Volume 1 : The Protocols* by - by W. Richard Stevens (ISBN: 0201633469) - This book provides detailed introduction to TCP/IP and includes diagnostic - programs which are publicly available. - -- *TCP/IP Illustrated, Volume 2 : The Implementation* by W. Richard - Stevens and Gary Wright (ISBN: 020163354X) - This book focuses on implementation issues regarding TCP/IP. The - treat for RTEMS users is that the implementation covered is the BSD - stack with most of the source code described in detail. - -- *UNIX Network Programming, Volume 1 : 2nd Edition* by W. Richard - Stevens (ISBN: 0-13-490012-X) - This book describes how to write basic TCP/IP applications, again with primary - focus on the BSD stack. - -.. COMMENT: Written by Eric Norum - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Network Task Structure and Data Flow -#################################### - -A schematic diagram of the tasks and message *mbuf* queues in a -simple RTEMS networking application is shown in the following -figure: - -.. image:: images/networkflow.jpg - - -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. - -.. COMMENT: Written by Eric Norum - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Networking Driver -################# - -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``c/src/lib/libbsp/m68k/gen68360/network`` directory in the RTEMS -source code distribution. Having a copy of this driver at -hand when reading the following notes will help significantly. - -Learn about the network device -============================== - -Before starting to write the network driver become 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. - -- 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? - -- If the device uses DMA, is it capable of forming a single - outgoing packet from multiple fragments scattered in separate - memory buffers? - -- If the device uses DMA, is it capable of chaining multiple - outgoing packets, or does each outgoing packet require - intervention by the driver? - -- Does the device automatically pad short frames to the minimum - 64 bytes or does the driver have to supply the padding? - -- Does the device automatically retry a transmission on detection - of a collision? - -- 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? - -- 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? - -- How is the device Ethernet address set? How is the device - programmed to accept or reject broadcast and multicast packets? - -- 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? - -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. - -Understand the network scheduling conventions -============================================= - -When writing code for the driver transmit and receive tasks, -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 (``rtems_bsdnet_semaphore``). -The transmit and receive tasks must abide by this protocol. Be very -careful to avoid ‘deadly embraces’ with the other network tasks. -A number of routines are provided to make it easier for the network -driver code to conform to the network task scheduling conventions. - -- ``void rtems_bsdnet_semaphore_release(void)`` - This function releases the network semaphore. - The network driver tasks must call this function immediately before - making any blocking RTEMS request. - -- ``void rtems_bsdnet_semaphore_obtain(void)`` - This function obtains the network semaphore. - If a network driver task has released the network semaphore to allow other - network-related tasks to run while the task blocks, then this function must - be called to reobtain the semaphore immediately after the return from the - blocking RTEMS request. - -- ``rtems_bsdnet_event_receive(rtems_event_set, rtems_option, rtems_interval, rtems_event_set \*)`` - The network driver task should call this function when it wishes to wait - for an event. This function releases the network semaphore, - calls ``rtems_event_receive`` to wait for the specified event - or events and reobtains the semaphore. - The value returned is the value returned by the ``rtems_event_receive``. - -Network Driver Makefile -======================= - -Network drivers are considered part of the BSD network package and as such -are to be compiled with the appropriate flags. This can be accomplished by -adding ``-D__INSIDE_RTEMS_BSD_TCPIP_STACK__`` to the ``command line``. -If the driver is inside the RTEMS source tree or is built using the -RTEMS application Makefiles, then adding the following line accomplishes -this: -.. code:: c - - DEFINES += -D__INSIDE_RTEMS_BSD_TCPIP_STACK__ - -This is equivalent to the following list of definitions. Early versions -of the RTEMS BSD network stack required that all of these be defined. - -.. code:: c - - -D_COMPILING_BSD_KERNEL_ -DKERNEL -DINET -DNFS \\ - -DDIAGNOSTIC -DBOOTP_COMPAT - -Defining these macros tells the network header files that the driver -is to be compiled with extended visibility into the network stack. This -is in sharp contrast to applications that simply use the network stack. -Applications do not require this level of visibility and should stick -to the portable application level API. - -As a direct result of being logically internal to the network stack, -network drivers use the BSD memory allocation routines This means, -for example, that malloc takes three arguments. See the SONIC -device driver (``c/src/lib/libchip/network/sonic.c``) for an example -of this. Because of this, network drivers should not include````. Doing so will result in conflicting definitions -of ``malloc()``. - -*Application level* code including network servers such as the FTP -daemon are *not* part of the BSD kernel network code and should not be -compiled with the BSD network flags. They should include```` and not define the network stack visibility -macros. - -Write the 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``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: - -``ifp->if_softc`` - Pointer to the device-dependent data. The first entry - in the device-dependent data structure must be an ``arpcom`` - structure. - -``ifp->if_name`` - The name of the device. The network stack uses this string - and the device number for device name lookups. The device name should - be obtained from the ``name`` entry in the configuration structure. - -``ifp->if_unit`` - The device number. The network stack uses this number and the - device name for device name lookups. For example, if``ifp->if_name`` is ‘``scc``’ and ``ifp->if_unit`` is ‘``1``’, - the full device name would be ‘``scc1``’. The unit number should be - obtained from the ‘name’ entry in the configuration structure. - -``ifp->if_mtu`` - The maximum transmission unit for the device. For Ethernet - devices this value should almost always be 1500. - -``ifp->if_flags`` - The device flags. Ethernet devices should set the flags - to ``IFF_BROADCAST|IFF_SIMPLEX``, indicating that the - device can broadcast packets to multiple destinations - and does not receive and transmit at the same time. - -``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 ``ifqmaxlen``. - -``ifp->if_init`` - The address of the driver initialization function. - -``ifp->if_start`` - The address of the driver start function. - -``ifp->if_ioctl`` - The address of the driver ioctl function. - -``ifp->if_output`` - The address of the output function. Ethernet devices - should set this to ``ether_output``. - -RTEMS provides a function to parse the driver name in the -configuration structure into a device name and unit number. -.. code:: c - - int rtems_bsdnet_parse_driver_name ( - const struct rtems_bsdnet_ifconfig \*config, - char \**namep - ); - -The function takes two arguments; a pointer to the configuration -structure and a pointer to a pointer to a character. The function -parses the configuration name entry, allocates memory for the driver -name, places the driver name in this memory, sets the second argument -to point to the name and returns the unit number. -On error, a message is printed and -1 is returned. - -Once the attach function has set up the above entries it must link the -driver data structure onto the list of devices by -calling ``if_attach``. Ethernet devices should then -call ``ether_ifattach``. Both functions take a pointer to the -device’s ``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. - -Write the 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 ``IFF_OACTIVE`` bit in the -device’s ``if_flags`` is not set. - -For many devices this function need only set the ``IFF_OACTIVE`` bit in the``if_flags`` and send an event to the transmit task -indicating that a packet is in the driver transmit queue. - -Write the Driver Initialization Function. -========================================= - -This function should initialize the device, attach to interrupt handler, -and start the driver transmit and receive tasks. The function -.. code:: c - - rtems_id - rtems_bsdnet_newproc (char \*name, - int stacksize, - void(\*entry)(void \*), - void \*arg); - -should be used to start the driver tasks. - -Note that the network stack may call the driver initialization function more -than once. -Make sure multiple versions of the receive and transmit tasks are not accidentally -started. - -Write the 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 ``IFF_OACTIVE`` bit in ``if_flags`` and block until another outgoing -packet is queued. - -Write the Driver Receive Task -============================= - -This task should block until a packet arrives from the device. If the -device is an Ethernet interface the function ``ether_input`` should be called -to forward the packet to the network stack. The arguments to ``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. - -Write the 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. - -Write the Driver IOCTL Function -=============================== - -This function handles ioctl requests directed at the device. The ioctl -commands which must be handled are: - -``SIOCGIFADDR`` - -``SIOCSIFADDR`` - - If the device is an Ethernet interface these - commands should be passed on to ``ether_ioctl``. - -``SIOCSIFFLAGS`` - - This command should be used to start or stop the device, - depending on the state of the interface ``IFF_UP`` and``IFF_RUNNING`` bits in ``if_flags``: - - ``IFF_RUNNING`` - - Stop the device. - - ``IFF_UP`` - - Start the device. - - ``IFF_UP|IFF_RUNNING`` - - Stop then start the device. - - ``0`` - - Do nothing. - -Write the Driver Statistic-Printing Function -============================================ - -This function should print the values of any statistic/diagnostic -counters the network driver may use. The driver ioctl function should call -the statistic-printing function when the ioctl command is``SIO_RTEMS_SHOW_STATS``. - -.. COMMENT: Written by Eric Norum - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Using Networking in an RTEMS Application -######################################## - -Makefile changes -================ - -Including the required managers -------------------------------- - -The FreeBSD networking code requires several RTEMS managers -in the application: -.. code:: c - - MANAGERS = io event semaphore - -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 ``CFLAGS_LD`` definition as shown below: -.. code:: c - - CFLAGS_LD += -Wl,--defsym -Wl,HeapSize=0x80000 - -This sets aside 512 kbytes of memory for the heap. - -System Configuration -==================== - -The networking tasks allocate some RTEMS objects. These -must be accounted for in the application configuration table. The following -lists the requirements. - -*TASKS* - One network task plus a receive and transmit task for each device. - -*SEMAPHORES* - One network semaphore plus one syslog mutex semaphore if the application uses - openlog/syslog. - -*EVENTS* - The network stack uses ``RTEMS_EVENT_24`` and ``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. - -Initialization -============== - -Additional include files ------------------------- - -The source file which declares the network configuration -structures and calls the network initialization function must include -.. code:: c - - #include - -Network Configuration ---------------------- - -The network configuration is specified by declaring -and initializing the ``rtems_bsdnet_config`` -structure. -.. code:: c - - struct rtems_bsdnet_config { - /* - * This entry points to the head of the ifconfig chain. - \*/ - struct rtems_bsdnet_ifconfig \*ifconfig; - /* - * This entry should be rtems_bsdnet_do_bootp if BOOTP - * is being used to configure the network, and NULL - * if BOOTP is not being used. - \*/ - void (\*bootp)(void); - /* - * The remaining items can be initialized to 0, in - * which case the default value will be used. - \*/ - rtems_task_priority network_task_priority; /* 100 \*/ - unsigned long mbuf_bytecount; /* 64 kbytes \*/ - unsigned long mbuf_cluster_bytecount; /* 128 kbytes \*/ - char \*hostname; /* BOOTP \*/ - char \*domainname; /* BOOTP \*/ - char \*gateway; /* BOOTP \*/ - char \*log_host; /* BOOTP \*/ - char \*name_server[3]; /* BOOTP \*/ - char \*ntp_server[3]; /* BOOTP \*/ - unsigned long sb_efficiency; /* 2 \*/ - /* UDP TX: 9216 bytes \*/ - unsigned long udp_tx_buf_size; - /* UDP RX: 40 * (1024 + sizeof(struct sockaddr_in)) \*/ - unsigned long udp_rx_buf_size; - /* TCP TX: 16 * 1024 bytes \*/ - unsigned long tcp_tx_buf_size; - /* TCP TX: 16 * 1024 bytes \*/ - unsigned long tcp_rx_buf_size; - /* Default Network Tasks CPU Affinity \*/ - #ifdef RTEMS_SMP - const cpu_set_t \*network_task_cpuset; - size_t network_task_cpuset_size; - #endif - }; - -The structure entries are described in the following table. -If your application uses BOOTP/DHCP 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. - -``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. - -``void (\*bootp)(void)`` - - This entry should be set to ``rtems_bsdnet_do_bootp`` if your - application by default uses the BOOTP/DHCP client protocol to obtain - network configuration information. It should be set to ``NULL`` if - your application does not use BOOTP/DHCP. - You can also use ``rtems_bsdnet_do_bootp_rootfs`` to have a set of - standard files created with the information return by the BOOTP/DHCP - protocol. The IP address is added to :file:`/etc/hosts` with the host - name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server’s address is also - added to :file:`/etc/hosts`. The domain name server listed in the - BOOTP/DHCP information are added to :file:`/etc/resolv.conf`. A``search`` record is also added if a domain is returned. The files - are created if they do not exist. - The default ``rtems_bsdnet_do_bootp`` and``rtems_bsdnet_do_bootp_rootfs`` handlers will loop for-ever - waiting for a BOOTP/DHCP server to respond. If an error is detected - such as not valid interface or valid hardware address the target will - reboot allowing any hardware reset to correct itself. - You can provide your own custom handler which allows you to perform - an initialization that meets your specific system requirements. For - example you could try BOOTP/DHCP then enter a configuration tool if no - server is found allowing the user to switch to a static configuration. - -``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. - -``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. - -``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. - -``char \*hostname`` - The host name of the system. - If this, or any of the following, entries are ``NULL`` the value - may be obtained from a BOOTP/DHCP server. - -``char \*domainname`` - The name of the Internet domain to which the system belongs. - -``char \*gateway`` - The Internet host number of the network gateway machine, - specified in ’dotted decimal’ (``129.128.4.1``) form. - -``char \*log_host`` - The Internet host number of the machine to which ``syslog`` messages - will be sent. - -``char \*name_server[3]`` - The Internet host numbers of up to three machines to be used as - Internet Domain Name Servers. - -``char \*ntp_server[3]`` - The Internet host numbers of up to three machines to be used as - Network Time Protocol (NTP) Servers. - -``unsigned long sb_efficiency`` - This is the first of five configuration parameters related to - the amount of memory each socket may consume for buffers. The - TCP/IP stack reserves buffers (e.g. mbufs) for each open socket. The - TCP/IP stack has different limits for the transmit and receive - buffers associated with each TCP and UDP socket. By tuning these - parameters, the application developer can make trade-offs between - memory consumption and performance. The default parameters favor - performance over memory consumption. Seehttp://www.rtems.org/ml/rtems-users/2004/february/msg00200.html - for more details but note that after the RTEMS 4.8 release series, - the sb_efficiency default was changed from ``8`` to ``2``. - The user should also be aware of the ``SO_SNDBUF`` and ``SO_RCVBUF`` - IO control operations. These can be used to specify the - send and receive buffer sizes for a specific socket. There - is no standard IO control to change the ``sb_efficiency`` factor. - The ``sb_efficiency`` parameter is a buffering factor used - in the implementation of the TCP/IP stack. The default is ``2`` - which indicates double buffering. When allocating memory for each - socket, this number is multiplied by the buffer sizes for that socket. - -``unsigned long udp_tx_buf_size`` - - This configuration parameter specifies the maximum amount of - buffer memory which may be used for UDP sockets to transmit - with. The default size is 9216 bytes which corresponds to - the maximum datagram size. - -``unsigned long udp_rx_buf_size`` - - This configuration parameter specifies the maximum amount of - buffer memory which may be used for UDP sockets to receive - into. The default size is the following length in bytes: - - .. code:: c - - 40 * (1024 + sizeof(struct sockaddr_in) - -``unsigned long tcp_tx_buf_size`` - - This configuration parameter specifies the maximum amount of - buffer memory which may be used for TCP sockets to transmit - with. The default size is sixteen kilobytes. - -``unsigned long tcp_rx_buf_size`` - - This configuration parameter specifies the maximum amount of - buffer memory which may be used for TCP sockets to receive - into. The default size is sixteen kilobytes. - -``const cpu_set_t \*network_task_cpuset`` - - This configuration parameter specifies the CPU affinity of the - network task. If set to ``0`` the network task can be scheduled on - any CPU. Only available in SMP configurations. - -``size_t network_task_cpuset_size`` - - This configuration parameter specifies the size of the``network_task_cpuset`` used. Only available in SMP configurations. - -In addition, the following fields in the ``rtems_bsdnet_ifconfig`` -are of interest. - -*int port* - The I/O port number (ex: 0x240) on which the external Ethernet - can be accessed. - -*int irno* - The interrupt number of the external Ethernet controller. - -*int bpar* - The address of the shared memory on the external Ethernet controller. - -Network device configuration ----------------------------- - -Network devices are specified and configured by declaring and initializing a``struct rtems_bsdnet_ifconfig`` structure for each network device. - -The structure entries are described in the following table. An application -which uses a single network interface, gets network configuration information -from a BOOTP/DHCP server, and uses the default values for all driver -parameters needs to initialize only the first two entries in the -structure. - -``char \*name`` - The full name of the network device. This name consists of the - driver name and the unit number (e.g. ``"scc1"``). - The ``bsp.h`` include file usually defines RTEMS_BSP_NETWORK_DRIVER_NAME as - the name of the primary (or only) network driver. - -``int (\*attach)(struct rtems_bsdnet_ifconfig \*conf)`` - The address of the driver ``attach`` function. The network - initialization function calls this function to configure the driver and - attach it to the network stack. - The ``bsp.h`` include file usually defines RTEMS_BSP_NETWORK_DRIVER_ATTACH as - the name of the attach function of the primary (or only) network driver. - -``struct rtems_bsdnet_ifconfig \*next`` - A pointer to the network device configuration structure for the next network - interface, or ``NULL`` if this is the configuration structure of the - last network interface. - -``char \*ip_address`` - The Internet address of the device, - specified in ‘dotted decimal’ (``129.128.4.2``) form, or ``NULL`` - if the device configuration information is being obtained from a - BOOTP/DHCP server. - -``char \*ip_netmask`` - The Internet inetwork mask of the device, - specified in ‘dotted decimal’ (``255.255.255.0``) form, or ``NULL`` - if the device configuration information is being obtained from a - BOOTP/DHCP server. - -``void \*hardware_address`` - The hardware address of the device, or ``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). - -``int ignore_broadcast`` - Zero if the device is to accept broadcast packets, non-zero if the device - is to ignore broadcast packets. - -``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). - -``int rbuf_count`` - The number of receive buffers to use, or zero if the driver is to - choose a default value - -``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. - -A complete network configuration specification can be as simple as the one -shown in the following example. -This configuration uses a single network interface, gets -network configuration information -from a BOOTP/DHCP server, and uses the default values for all driver -parameters. -.. code:: c - - static struct rtems_bsdnet_ifconfig netdriver_config = { - RTEMS_BSP_NETWORK_DRIVER_NAME, - RTEMS_BSP_NETWORK_DRIVER_ATTACH - }; - struct rtems_bsdnet_config rtems_bsdnet_config = { - &netdriver_config, - rtems_bsdnet_do_bootp, - }; - -Network initialization ----------------------- - -The networking tasks must be started before any network I/O operations -can be performed. This is done by calling: - -.. code:: c - - rtems_bsdnet_initialize_network (); - -This function is declared in ``rtems/rtems_bsdnet.h``. -t returns 0 on success and -1 on failure with an error code -in ``errno``. It is not possible to undo the effects of -a partial initialization, though, so the function can be -called only once irregardless of the return code. Consequently, -if the condition for the failure can be corrected, the -system must be reset to permit another network initialization -attempt. - -Application Programming Interface -================================= - -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: - -- A given socket can be read or written by only one task at a time. - -- The ``select`` function only works for file descriptors associated - with sockets. - -- You must call ``openlog`` before calling any of the ``syslog`` functions. - -- *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: - - ``gethostbyaddr`` - - ``gethostbyname`` - - ``inet_ntoa`` - - (``inet_ntop`` is thread-safe, though). - -- The RTEMS network package gathers statistics. - -- Addition of a mechanism to "tap onto" an interface - and monitor every packet received and transmitted. - -- Addition of ``SO_SNDWAKEUP`` and ``SO_RCVWAKEUP`` socket options. - -Some of the new features are discussed in more detail in the following -sections. - -Network Statistics ------------------- - -There are a number of functions to print statistics gathered by -the network stack. -These function are declared in ``rtems/rtems_bsdnet.h``. - -``rtems_bsdnet_show_if_stats`` - Display statistics gathered by network interfaces. - -``rtems_bsdnet_show_ip_stats`` - Display IP packet statistics. - -``rtems_bsdnet_show_icmp_stats`` - Display ICMP packet statistics. - -``rtems_bsdnet_show_tcp_stats`` - Display TCP packet statistics. - -``rtems_bsdnet_show_udp_stats`` - Display UDP packet statistics. - -``rtems_bsdnet_show_mbuf_stats`` - Display mbuf statistics. - -``rtems_bsdnet_show_inet_routes`` - Display the routing table. - -Tapping Into an Interface -------------------------- - -RTEMS add two new ioctls to the BSD networking code: -SIOCSIFTAP and SIOCGIFTAP. These may be used to set and get a*tap function*. The tap function will be called for every -Ethernet packet received by the interface. - -These are called like other interface ioctls, such as SIOCSIFADDR. -When setting the tap function with SIOCSIFTAP, set the ifr_tap field -of the ifreq struct to the tap function. When retrieving the tap -function with SIOCGIFTAP, the current tap function will be returned in -the ifr_tap field. To stop tapping packets, call SIOCSIFTAP with a -ifr_tap field of 0. - -The tap function is called like this: -.. code:: c - - int tap (struct ifnet \*, struct ether_header \*, struct mbuf \*) - -The tap function should return 1 if the packet was fully handled, in -which case the caller will simply discard the mbuf. The tap function -should return 0 if the packet should be passed up to the higher -networking layers. - -The tap function is called with the network semaphore locked. It must -not make any calls on the application levels of the networking level -itself. It is safe to call other non-networking RTEMS functions. - -Socket Options --------------- - -RTEMS adds two new ``SOL_SOCKET`` level options for ``setsockopt`` and``getsockopt``: ``SO_SNDWAKEUP`` and ``SO_RCVWAKEUP``. For both, the -option value should point to a sockwakeup structure. The sockwakeup -structure has the following fields: -.. code:: c - - void (\*sw_pfn) (struct socket \*, caddr_t); - caddr_t sw_arg; - -These options are used to set a callback function to be called when, for -example, there is -data available from the socket (``SO_RCVWAKEUP``) and when there is space -available to accept data written to the socket (``SO_SNDWAKEUP``). - -If ``setsockopt`` is called with the ``SO_RCVWAKEUP`` option, and the``sw_pfn`` field is not zero, then when there is data -available to be read from -the socket, the function pointed to by the ``sw_pfn`` field will be -called. A pointer to the socket structure will be passed as the first -argument to the function. The ``sw_arg`` field set by the``SO_RCVWAKEUP`` call will be passed as the second argument to the function. - -If ``setsockopt`` is called with the ``SO_SNDWAKEUP`` -function, and the ``sw_pfn`` field is not zero, then when -there is space available to accept data written to the socket, -the function pointed to by the ``sw_pfn`` field -will be called. The arguments passed to the function will be as with``SO_SNDWAKEUP``. - -When the function is called, the network semaphore will be locked and -the callback function runs in the context of the networking task. -The function must be careful not to call any networking functions. It -is OK to call an RTEMS function; for example, it is OK to send an -RTEMS event. - -The purpose of these callback functions is to permit a more efficient -alternative to the select call when dealing with a large number of -sockets. - -The callbacks are called by the same criteria that the select -function uses for indicating "ready" sockets. In Stevens *Unix -Network Programming* on page 153-154 in the section "Under what Conditions -Is a Descriptor Ready?" you will find the definitive list of conditions -for readable and writable that also determine when the functions are -called. - -When the number of received bytes equals or exceeds the socket receive -buffer "low water mark" (default 1 byte) you get a readable callback. If -there are 100 bytes in the receive buffer and you only read 1, you will -not immediately get another callback. However, you will get another -callback after you read the remaining 99 bytes and at least 1 more byte -arrives. Using a non-blocking socket you should probably read until it -produces error EWOULDBLOCK and then allow the readable callback to tell -you when more data has arrived. (Condition 1.a.) - -For sending, when the socket is connected and the free space becomes at -or above the "low water mark" for the send buffer (default 4096 bytes) -you will receive a writable callback. You don’t get continuous callbacks -if you don’t write anything. Using a non-blocking write socket, you can -then call write until it returns a value less than the amount of data -requested to be sent or it produces error EWOULDBLOCK (indicating buffer -full and no longer writable). When this happens you can -try the write again, but it is often better to go do other things and -let the writable callback tell you when space is available to send -again. You only get a writable callback when the free space transitions -to above the "low water mark" and not every time you -write to a non-full send buffer. (Condition 2.a.) - -The remaining conditions enumerated by Stevens handle the fact that -sockets become readable and/or writable when connects, disconnects and -errors occur, not just when data is received or sent. For example, when -a server "listening" socket becomes readable it indicates that a client -has connected and accept can be called without blocking, not that -network data was received (Condition 1.c). - -Adding an IP Alias ------------------- - -The following code snippet adds an IP alias: -.. code:: c - - void addAlias(const char \*pName, const char \*pAddr, const char \*pMask) - { - struct ifaliasreq aliasreq; - struct sockaddr_in \*in; - /* initialize alias request \*/ - memset(&aliasreq, 0, sizeof(aliasreq)); - sprintf(aliasreq.ifra_name, pName); - /* initialize alias address \*/ - in = (struct sockaddr_in \*)&aliasreq.ifra_addr; - in->sin_family = AF_INET; - in->sin_len = sizeof(aliasreq.ifra_addr); - in->sin_addr.s_addr = inet_addr(pAddr); - /* initialize alias mask \*/ - in = (struct sockaddr_in \*)&aliasreq.ifra_mask; - in->sin_family = AF_INET; - in->sin_len = sizeof(aliasreq.ifra_mask); - in->sin_addr.s_addr = inet_addr(pMask); - /* call to setup the alias \*/ - rtems_bsdnet_ifconfig(pName, SIOCAIFADDR, &aliasreq); - } - -Thanks to `Mike Seirs `_ for this example -code. - -Adding a Default Route ----------------------- - -The function provided in this section is functionally equivalent to -the command ``route add default gw yyy.yyy.yyy.yyy``: -.. code:: c - - void mon_ifconfig(int argc, char \*argv[], unsigned32 command_arg, - bool verbose) - { - struct sockaddr_in ipaddr; - struct sockaddr_in dstaddr; - struct sockaddr_in netmask; - struct sockaddr_in broadcast; - char \*iface; - int f_ip = 0; - int f_ptp = 0; - int f_netmask = 0; - int f_up = 0; - int f_down = 0; - int f_bcast = 0; - int cur_idx; - int rc; - int flags; - bzero((void*) &ipaddr, sizeof(ipaddr)); - bzero((void*) &dstaddr, sizeof(dstaddr)); - bzero((void*) &netmask, sizeof(netmask)); - bzero((void*) &broadcast, sizeof(broadcast)); - ipaddr.sin_len = sizeof(ipaddr); - ipaddr.sin_family = AF_INET; - dstaddr.sin_len = sizeof(dstaddr); - dstaddr.sin_family = AF_INET; - netmask.sin_len = sizeof(netmask); - netmask.sin_family = AF_INET; - broadcast.sin_len = sizeof(broadcast); - broadcast.sin_family = AF_INET; - cur_idx = 0; - if (argc <= 1) { - /* display all interfaces \*/ - iface = NULL; - cur_idx += 1; - } else { - iface = argv[1]; - if (isdigit(\*argv[2])) { - if (inet_pton(AF_INET, argv[2], &ipaddr.sin_addr) < 0) { - printf("bad ip address: %s\\n", argv[2]); - return; - } - f_ip = 1; - cur_idx += 3; - } else { - cur_idx += 2; - } - } - if ((f_down !=0) && (f_ip != 0)) { - f_up = 1; - } - while(argc > cur_idx) { - if (strcmp(argv[cur_idx], "up") == 0) { - f_up = 1; - if (f_down != 0) { - printf("Can't make interface up and down\\n"); - } - } else if(strcmp(argv[cur_idx], "down") == 0) { - f_down = 1; - if (f_up != 0) { - printf("Can't make interface up and down\\n"); - } - } else if(strcmp(argv[cur_idx], "netmask") == 0) { - if ((cur_idx + 1) >= argc) { - printf("No netmask address\\n"); - return; - } - if (inet_pton(AF_INET, argv[cur_idx+1], &netmask.sin_addr) < 0) { - printf("bad netmask: %s\\n", argv[cur_idx]); - return; - } - f_netmask = 1; - cur_idx += 1; - } else if(strcmp(argv[cur_idx], "broadcast") == 0) { - if ((cur_idx + 1) >= argc) { - printf("No broadcast address\\n"); - return; - } - if (inet_pton(AF_INET, argv[cur_idx+1], &broadcast.sin_addr) < 0) { - printf("bad broadcast: %s\\n", argv[cur_idx]); - return; - } - f_bcast = 1; - cur_idx += 1; - } else if(strcmp(argv[cur_idx], "pointopoint") == 0) { - if ((cur_idx + 1) >= argc) { - printf("No pointopoint address\\n"); - return; - } - if (inet_pton(AF_INET, argv[cur_idx+1], &dstaddr.sin_addr) < 0) { - printf("bad pointopoint: %s\\n", argv[cur_idx]); - return; - } - f_ptp = 1; - cur_idx += 1; - } else { - printf("Bad parameter: %s\\n", argv[cur_idx]); - return; - } - cur_idx += 1; - } - printf("ifconfig "); - if (iface != NULL) { - printf("%s ", iface); - if (f_ip != 0) { - char str[256]; - inet_ntop(AF_INET, &ipaddr.sin_addr, str, 256); - printf("%s ", str); - } - if (f_netmask != 0) { - char str[256]; - inet_ntop(AF_INET, &netmask.sin_addr, str, 256); - printf("netmask %s ", str); - } - if (f_bcast != 0) { - char str[256]; - inet_ntop(AF_INET, &broadcast.sin_addr, str, 256); - printf("broadcast %s ", str); - } - if (f_ptp != 0) { - char str[256]; - inet_ntop(AF_INET, &dstaddr.sin_addr, str, 256); - printf("pointopoint %s ", str); - } - if (f_up != 0) { - printf("up\\n"); - } else if (f_down != 0) { - printf("down\\n"); - } else { - printf("\\n"); - } - } - if ((iface == NULL) \|| ((f_ip == 0) && (f_down == 0) && (f_up == 0))) { - rtems_bsdnet_show_if_stats(); - return; - } - flags = 0; - if (f_netmask) { - rc = rtems_bsdnet_ifconfig(iface, SIOCSIFNETMASK, &netmask); - if (rc < 0) { - printf("Could not set netmask: %s\\n", strerror(errno)); - return; - } - } - if (f_bcast) { - rc = rtems_bsdnet_ifconfig(iface, SIOCSIFBRDADDR, &broadcast); - if (rc < 0) { - printf("Could not set broadcast: %s\\n", strerror(errno)); - return; - } - } - if (f_ptp) { - rc = rtems_bsdnet_ifconfig(iface, SIOCSIFDSTADDR, &dstaddr); - if (rc < 0) { - printf("Could not set destination address: %s\\n", strerror(errno)); - return; - } - flags \|= IFF_POINTOPOINT; - } - /* This must come _after_ setting the netmask, broadcast addresses \*/ - if (f_ip) { - rc = rtems_bsdnet_ifconfig(iface, SIOCSIFADDR, &ipaddr); - if (rc < 0) { - printf("Could not set IP address: %s\\n", strerror(errno)); - return; - } - } - if (f_up != 0) { - flags \|= IFF_UP; - } - if (f_down != 0) { - printf("Warning: taking interfaces down is not supported\\n"); - } - rc = rtems_bsdnet_ifconfig(iface, SIOCSIFFLAGS, &flags); - if (rc < 0) { - printf("Could not set interface flags: %s\\n", strerror(errno)); - return; - } - } - void mon_route(int argc, char \*argv[], unsigned32 command_arg, - bool verbose) - { - int cmd; - struct sockaddr_in dst; - struct sockaddr_in gw; - struct sockaddr_in netmask; - int f_host; - int f_gw = 0; - int cur_idx; - int flags; - int rc; - memset(&dst, 0, sizeof(dst)); - memset(&gw, 0, sizeof(gw)); - memset(&netmask, 0, sizeof(netmask)); - dst.sin_len = sizeof(dst); - dst.sin_family = AF_INET; - dst.sin_addr.s_addr = inet_addr("0.0.0.0"); - gw.sin_len = sizeof(gw); - gw.sin_family = AF_INET; - gw.sin_addr.s_addr = inet_addr("0.0.0.0"); - netmask.sin_len = sizeof(netmask); - netmask.sin_family = AF_INET; - netmask.sin_addr.s_addr = inet_addr("255.255.255.0"); - if (argc < 2) { - rtems_bsdnet_show_inet_routes(); - return; - } - if (strcmp(argv[1], "add") == 0) { - cmd = RTM_ADD; - } else if (strcmp(argv[1], "del") == 0) { - cmd = RTM_DELETE; - } else { - printf("invalid command: %s\\n", argv[1]); - printf("\\tit should be 'add' or 'del'\\n"); - return; - } - if (argc < 3) { - printf("not enough arguments\\n"); - return; - } - if (strcmp(argv[2], "-host") == 0) { - f_host = 1; - } else if (strcmp(argv[2], "-net") == 0) { - f_host = 0; - } else { - printf("Invalid type: %s\\n", argv[1]); - printf("\\tit should be '-host' or '-net'\\n"); - return; - } - if (argc < 4) { - printf("not enough arguments\\n"); - return; - } - inet_pton(AF_INET, argv[3], &dst.sin_addr); - cur_idx = 4; - while(cur_idx < argc) { - if (strcmp(argv[cur_idx], "gw") == 0) { - if ((cur_idx +1) >= argc) { - printf("no gateway address\\n"); - return; - } - f_gw = 1; - inet_pton(AF_INET, argv[cur_idx + 1], &gw.sin_addr); - cur_idx += 1; - } else if(strcmp(argv[cur_idx], "netmask") == 0) { - if ((cur_idx +1) >= argc) { - printf("no netmask address\\n"); - return; - } - f_gw = 1; - inet_pton(AF_INET, argv[cur_idx + 1], &netmask.sin_addr); - cur_idx += 1; - } else { - printf("Unknown argument\\n"); - return; - } - cur_idx += 1; - } - flags = RTF_STATIC; - if (f_gw != 0) { - flags \|= RTF_GATEWAY; - } - if (f_host != 0) { - flags \|= RTF_HOST; - } - rc = rtems_bsdnet_rtrequest(cmd, &dst, &gw, &netmask, flags, NULL); - if (rc < 0) { - printf("Error adding route\\n"); - } - } - -Thanks to `Jay Monkman `_ for this example -code. - -Time Synchronization Using NTP ------------------------------- - -.. code:: c - - int rtems_bsdnet_synchronize_ntp (int interval, rtems_task_priority priority); - -If the interval argument is 0 the routine synchronizes the RTEMS time-of-day -clock with the first NTP server in the rtems_bsdnet_ntpserve array and -returns. The priority argument is ignored. - -If the interval argument is greater than 0, the routine also starts an -RTEMS task at the specified priority and polls the NTP server every -‘interval’ seconds. NOTE: This mode of operation has not yet been -implemented. - -On successful synchronization of the RTEMS time-of-day clock the routine -returns 0. If an error occurs a message is printed and the routine returns -1 -with an error code in errno. -There is no timeout – if there is no response from an NTP server the -routine will wait forever. - -.. COMMENT: Written by Eric Norum - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Testing the Driver -################## - -Preliminary Setup -================= - -The network used to test the driver should include at least: - -- 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. - -- An Ethernet network analyzer or a workstation with an - ‘Ethernet snoop’ program such as ``ethersnoop`` or``tcpdump``. - -- A workstation. - -During early debug, you should consider putting the target, workstation, -and snooper on a small network by themselves. This offers a few -advantages: - -- There is less traffic to look at on the snooper and for the target - to process while bringing the driver up. - -- Any serious errors will impact only your small network not a building - or campus network. You want to avoid causing any unnecessary problems. - -- Test traffic is easier to repeatably generate. - -- Performance measurements are not impacted by other systems on - the network. - -Debug Output -============ - -There are a number of sources of debug output that can be enabled -to aid in tracing the behavior of the network stack. The following -is a list of them: - -- mbuf activity - There are commented out calls to ``printf`` in the file``sys/mbuf.h`` in the network stack code. Uncommenting - these lines results in output when mbuf’s are allocated - and freed. This is very useful for finding memory leaks. - -- TX and RX queuing - There are commented out calls to ``printf`` in the file``net/if.h`` in the network stack code. Uncommenting - these lines results in output when packets are placed - on or removed from one of the transmit or receive packet - queues. These queues can be viewed as the boundary line - between a device driver and the network stack. If the - network stack is enqueuing packets to be transmitted that - the device driver is not dequeuing, then that is indicative - of a problem in the transmit side of the device driver. - Conversely, if the device driver is enqueueing packets - as it receives them (via a call to ``ether_input``) and - they are not being dequeued by the network stack, - then there is a problem. This situation would likely indicate - that the network server task is not running. - -- TCP state transitions - In the unlikely event that one would actually want to see - TCP state transitions, the ``TCPDEBUG`` macro can be defined - in the file ``opt_tcpdebug.h``. This results in the routine``tcp_trace()`` being called by the network stack and - the state transitions logged into the ``tcp_debug`` data - structure. If the variable ``tcpconsdebug`` in the file``netinet/tcp_debug.c`` is set to 1, then the state transitions - will also be printed to the console. - -Monitor Commands -================ - -There are a number of command available in the shell / monitor -to aid in tracing the behavior of the network stack. The following -is a list of them: - -- ``inet`` - This command shows the current routing information for the TCP/IP stack. Following is an - example showing the output of this command. - - .. code:: c - - Destination Gateway/Mask/Hw Flags Refs Use Expire Interface - 10.0.0.0 255.0.0.0 U 0 0 17 smc1 - 127.0.0.1 127.0.0.1 UH 0 0 0 lo0 - - In this example, there is only one network interface with an IP address of 10.8.1.1. This - link is currently not up. - Two routes that are shown are the default routes for the Ethernet interface (10.0.0.0) and the - loopback interface (127.0.0.1). - Since the stack comes from BSD, this command is very similar to the netstat command. For more - details on the network routing please look the following - URL: (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html) - For a quick reference to the flags, see the table below: - - ‘``U``’ - Up: The route is active. - - ‘``H``’ - Host: The route destination is a single host. - - ‘``G``’ - Gateway: Send anything for this destination on to this remote system, which - will figure out from there where to send it. - - ‘``S``’ - Static: This route was configured manually, not automatically generated by the - system. - - ‘``C``’ - Clone: Generates a new route based upon this route for machines we connect - to. This type of route is normally used for local networks. - - ‘``W``’ - WasCloned: Indicated a route that was auto-configured based upon a local area - network (Clone) route. - - ‘``L``’ - Link: Route involves references to Ethernet hardware. - -- ``mbuf`` - - This command shows the current MBUF statistics. An example of the command is shown below: - - .. code:: c - - ************ MBUF STATISTICS \************ - mbufs:4096 clusters: 256 free: 241 - drops: 0 waits: 0 drains: 0 - free:4080 data:16 header:0 socket:0 - pcb:0 rtable:0 htable:0 atable:0 - soname:0 soopts:0 ftable:0 rights:0 - ifaddr:0 control:0 oobdata:0 - -- ``if`` - - This command shows the current statistics for your Ethernet driver as long as the ioctl hook``SIO_RTEMS_SHOW_STATS`` has been implemented. Below is an example: - - .. code:: c - - ************ INTERFACE STATISTICS \************ - \***** smc1 \***** - Ethernet Address: 00:12:76:43:34:25 - Address:10.8.1.1 Broadcast Address:10.255.255.255 Net mask:255.0.0.0 - Flags: Up Broadcast Running Simplex - Send queue limit:50 length:0 Dropped:0 - SMC91C111 RTEMS driver A0.01 11/03/2002 Ian Caddy (ianc@microsol.iinet.net.au) - Rx Interrupts:0 Not First:0 Not Last:0 - Giant:0 Runt:0 Non-octet:0 - Bad CRC:0 Overrun:0 Collision:0 - Tx Interrupts:2 Deferred:0 Missed Hearbeat:0 - No Carrier:0 Retransmit Limit:0 Late Collision:0 - Underrun:0 Raw output wait:0 Coalesced:0 - Coalesce failed:0 Retries:0 - \***** lo0 \***** - Address:127.0.0.1 Net mask:255.0.0.0 - Flags: Up Loopback Running Multicast - Send queue limit:50 length:0 Dropped:0 - -- ``ip`` - This command show the IP statistics for the currently configured interfaces. - -- ``icmp`` - This command show the ICMP statistics for the currently configured interfaces. - -- ``tcp`` - This command show the TCP statistics for the currently configured interfaces. - -- ``udp`` - This command show the UDP statistics for the currently configured interfaces. - -Driver basic operation -====================== - -The network demonstration program ``netdemo`` may be used for these tests. - -- Edit ``networkconfig.h`` to reflect the values for your network. - -- Start with ``RTEMS_USE_BOOTP`` not defined. - -- Edit ``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. - -- Issue a ‘``u``’ command to send UDP - packets to the ‘discard’ port. - Verify that the packets appear on the network. - -- Issue a ‘``s``’ command to print the network and driver statistics. - -- On a workstation, add a static route to the target system. - -- On that same workstation try to ‘ping’ the target system. - Verify that the ICMP echo request and reply packets appear on the net. - -- Remove the static route to the target system. - Modify ``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. - -- Issue a ‘``t``’ command to send TCP - packets to the ‘discard’ port. - Verify that the packets appear on the network. - -- Issue a ‘``s``’ command to print the network and driver statistics. - -- Verify that you can telnet to ports 24742 - and 24743 on the target system from one or more - workstations on your network. - -BOOTP/DHCP operation -==================== - -Set up a BOOTP/DHCP server on the network. -Set define ``RTEMS USE_BOOT`` in ``networkconfig.h``. -Run the ``netdemo`` test program. -Verify that the target system configures itself from the BOOTP/DHCP server and -that all the above tests succeed. - -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. - -Giant packets -------------- - -- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` set to - a smaller value, say 514. - -- ‘Ping’ the driver from another workstation and verify - that frames larger than 514 bytes are correctly rejected. - -- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` restored to 1518. - -Resource Exhaustion -------------------- - -- Edit ``networkconfig.h`` - so that the driver is configured with just two receive and transmit descriptors. - -- Compile and run the ``netdemo`` program. - -- Verify that the program operates properly and that you can - still telnet to both the ports. - -- Display the driver statistics (Console ‘``s``’ command or telnet - ‘control-G’ character) and verify that: - - # The number of transmit interrupts is non-zero. - This indicates that all transmit descriptors have been in use at some time. - - # The number of missed packets is non-zero. - This indicates that all receive descriptors have been in use at some time. - -Cable Faults ------------- - -- Run the ``netdemo`` program. - -- Issue a ‘``u``’ console command to make the target machine transmit - a bunch of UDP packets. - -- While the packets are being transmitted, disconnect and reconnect the - network cable. - -- Display the network statistics and verify that the driver has - detected the loss of carrier. - -- Verify that you can still telnet to both ports on the target machine. - -Throughput ----------- - -Run the ``ttcp`` network benchmark program. -Transfer large amounts of data (100’s of megabytes) to and from the target -system. - -The procedure for testing throughput from a host to an RTEMS target -is as follows: - -# Download and start the ttcp program on the Target. - -# In response to the ``ttcp`` prompt, enter ``-s -r``. The - meaning of these flags is described in the ``ttcp.1`` manual page - found in the ``ttcp_orig`` subdirectory. - -# On the host run ``ttcp -s -t <>`` - -The procedure for testing throughput from an RTEMS target -to a Host is as follows: - -# On the host run ``ttcp -s -r``. - -# Download and start the ttcp program on the Target. - -# In response to the ``ttcp`` prompt, enter ``-s -t <>``. You need to type the - IP address of the host unless your Target is talking to your Domain Name - Server. - -To change the number of buffers, the buffer size, etc. you just add the -extra flags to the ``-t`` machine as specified in the ``ttcp.1`` -manual page found in the ``ttcp_orig`` subdirectory. - -.. COMMENT: Text Written by Jake Janovetz - -.. COMMENT: COPYRIGHT (c) 1988-2002. - -.. COMMENT: On-Line Applications Research Corporation (OAR). - -.. COMMENT: All rights reserved. - -Network Servers -############### - -RTEMS FTP Daemon -================ - -The RTEMS FTPD is a complete file transfer protocol (FTP) daemon -which can store, retrieve, and manipulate files on the local -filesystem. In addition, the RTEMS FTPD provides “hooks” -which are actions performed on received data. Hooks are useful -in situations where a destination file is not necessarily -appropriate or in cases when a formal device driver has not yet -been implemented. - -This server was implemented and documented by Jake Janovetz -(janovetz@tempest.ece.uiuc.edu). - -Configuration Parameters ------------------------- - -The configuration structure for FTPD is as follows: -.. code:: c - - struct rtems_ftpd_configuration - { - rtems_task_priority priority; /* FTPD task priority \*/ - unsigned long max_hook_filesize; /* Maximum buffersize \*/ - /* for hooks \*/ - int port; /* Well-known port \*/ - struct rtems_ftpd_hook \*hooks; /* List of hooks \*/ - }; - -The FTPD task priority is specified with ``priority``. Because -hooks are not saved as files, the received data is placed in an -allocated buffer. ``max_hook_filesize`` specifies the maximum -size of this buffer. Finally, ``hooks`` is a pointer to the -configured hooks structure. - -Initializing FTPD (Starting the daemon) ---------------------------------------- - -Starting FTPD is done with a call to ``rtems_initialize_ftpd()``. -The configuration structure must be provided in the application -source code. Example hooks structure and configuration structure -folllow. -.. code:: c - - struct rtems_ftpd_hook ftp_hooks[] = - { - {"untar", Untar_FromMemory}, - {NULL, NULL} - }; - struct rtems_ftpd_configuration rtems_ftpd_configuration = - { - 40, /* FTPD task priority \*/ - 512*1024, /* Maximum hook 'file' size \*/ - 0, /* Use default port \*/ - ftp_hooks /* Local ftp hooks \*/ - }; - -Specifying 0 for the well-known port causes FTPD to use the -UNIX standard FTPD port (21). - -Using Hooks ------------ - -In the example above, one hook was installed. The hook causes -FTPD to call the function ``Untar_FromMemory`` when the -user sends data to the file ``untar``. The prototype for -the ``untar`` hook (and hooks, in general) is: -.. code:: c - - int Untar_FromMemory(unsigned char \*tar_buf, unsigned long size); - -An example FTP transcript which exercises this hook is: -.. code:: c - - 220 RTEMS FTP server (Version 1.0-JWJ) ready. - Name (dcomm0:janovetz): John Galt - 230 User logged in. - Remote system type is RTEMS. - ftp> bin - 200 Type set to I. - ftp> dir - 200 PORT command successful. - 150 ASCII data connection for LIST. - drwxrwx--x 0 0 268 dev - drwxrwx--x 0 0 0 TFTP - 226 Transfer complete. - ftp> put html.tar untar - local: html.tar remote: untar - 200 PORT command successful. - 150 BINARY data connection. - 210 File transferred successfully. - 471040 bytes sent in 0.48 secs (9.6e+02 Kbytes/sec) - ftp> dir - 200 PORT command successful. - 150 ASCII data connection for LIST. - drwxrwx--x 0 0 268 dev - drwxrwx--x 0 0 0 TFTP - drwxrwx--x 0 0 3484 public_html - 226 Transfer complete. - ftp> quit - 221 Goodbye. - -.. COMMENT: RTEMS Remote Debugger Server Specifications - -.. COMMENT: Written by: Emmanuel Raguet - -DEC 21140 Driver -################ - -DEC 21240 Driver Introduction -============================= - -.. COMMENT: XXX add back in cross reference to list of boards. - -One aim of our project is to port RTEMS on a standard PowerPC platform. -To achieve it, we have chosen a Motorola MCP750 board. This board includes -an Ethernet controller based on a DEC21140 chip. Because RTEMS has a -TCP/IP stack, we will -have to develop the DEC21140 related ethernet driver for the PowerPC port of -RTEMS. As this controller is able to support 100Mbps network and as there is -a lot of PCI card using this DEC chip, we have decided to first -implement this driver on an Intel PC386 target to provide a solution for using -RTEMS on PC with the 100Mbps network and then to port this code on PowerPC in -a second phase. - -The aim of this document is to give some PCI board generalities and -to explain the software architecture of the RTEMS driver. Finally, we will see -what will be done for ChorusOs and Netboot environment . - -Document Revision History -========================= - -*Current release*: - -- Current applicable release is 1.0. - -*Existing releases*: - -- 1.0 : Released the 10/02/98. First version of this document. - -- 0.1 : First draft of this document - -*Planned releases*: - -- None planned today. - -DEC21140 PCI Board Generalities -=============================== - -.. COMMENT: XXX add crossreference to PCI Register Figure - -This chapter describes rapidely the PCI interface of this Ethernet controller. -The board we have chosen for our PC386 implementation is a D-Link DFE-500TX. -This is a dual-speed 10/100Mbps Ethernet PCI adapter with a DEC21140AF chip. -Like other PCI devices, this board has a PCI device’s header containing some -required configuration registers, as shown in the PCI Register Figure. -By reading -or writing these registers, a driver can obtain information about the type of -the board, the interrupt it uses, the mapping of the chip specific registers, ... - -On Intel target, the chip specific registers can be accessed via 2 -methods : I/O port access or PCI address mapped access. We have chosen to implement -the PCI address access to obtain compatible source code to the port the driver -on a PowerPC target. - -.. COMMENT: PCI Device's Configuration Header Space Format - - -.. image:: images/PCIreg.jpg - - -.. COMMENT: XXX add crossreference to PCI Register Figure - -On RTEMS, a PCI API exists. We have used it to configure the board. After initializing -this PCI module via the ``pci_initialize()`` function, we try to detect -the DEC21140 based ethernet board. This board is characterized by its Vendor -ID (0x1011) and its Device ID (0x0009). We give these arguments to the``pcib_find_by_deviceid`` -function which returns , if the device is present, a pointer to the configuration -header space (see PCI Registers Fgure). Once this operation performed, -the driver -is able to extract the information it needs to configure the board internal -registers, like the interrupt line, the base address,... The board internal -registers will not be detailled here. You can find them in *DIGITAL -Semiconductor 21140A PCI Fast Ethernet LAN Controller -- Hardware Reference Manual*. - -.. COMMENT: fix citation - -RTEMS Driver Software Architecture -================================== - -In this chapter will see the initialization phase, how the controller uses the -host memory and the 2 threads launched at the initialization time. - -Initialization phase --------------------- - -The DEC21140 Ethernet driver keeps the same software architecture than the other -RTEMS ethernet drivers. The only API the programmer can use is the ``rtems_dec21140_driver_attach````(struct rtems_bsdnet_ifconfig \*config)`` function which -detects the board and initializes the associated data structure (with registers -base address, entry points to low-level initialization function,...), if the -board is found. - -Once the attach function executed, the driver initializes the DEC -chip. Then the driver connects an interrupt handler to the interrupt line driven -by the Ethernet controller (the only interrupt which will be treated is the -receive interrupt) and launches 2 threads : a receiver thread and a transmitter -thread. Then the driver waits for incoming frame to give to the protocol stack -or outcoming frame to send on the physical link. - -Memory Buffer -------------- - -.. COMMENT: XXX add cross reference to Problem - -This DEC chip uses the host memory to store the incoming Ethernet frames and -the descriptor of these frames. We have chosen to use 7 receive buffers and -1 transmit buffer to optimize memory allocation due to cache and paging problem -that will be explained in the section *Encountered Problems*. - -To reference these buffers to the DEC chip we use a buffer descriptors -ring. The descriptor structure is defined in the Buffer Descriptor Figure. -Each descriptor -can reference one or two memory buffers. We choose to use only one buffer of -1520 bytes per descriptor. - -The difference between a receive and a transmit buffer descriptor -is located in the status and control bits fields. We do not give details here, -please refer to the \[DEC21140 Hardware Manual]. - -.. COMMENT: Buffer Descriptor - - -.. image:: images/recvbd.jpg - - -Receiver Thread ---------------- - -This thread is event driven. Each time a DEC PCI board interrupt occurs, the -handler checks if this is a receive interrupt and send an event “reception” -to the receiver thread which looks into the entire buffer descriptors ring the -ones that contain a valid incoming frame (bit OWN=0 means descriptor belongs -to host processor). Each valid incoming ethernet frame is sent to the protocol -stack and the buffer descriptor is given back to the DEC board (the host processor -reset bit OWN, which means descriptor belongs to 21140). - -Transmitter Thread ------------------- - -This thread is also event driven. Each time an Ethernet frame is put in the -transmit queue, an event is sent to the transmit thread, which empty the queue -by sending each outcoming frame. Because we use only one transmit buffer, we -are sure that the frame is well-sent before sending the next. - -Encountered Problems -==================== - -On Intel PC386 target, we were faced with a problem of memory cache management. -Because the DEC chip uses the host memory to store the incoming frame and because -the DEC21140 configuration registers are mapped into the PCI address space, -we must ensure that the data read (or written) by the host processor are the -ones written (or read) by the DEC21140 device in the host memory and not old -data stored in the cache memory. Therefore, we had to provide a way to manage -the cache. This module is described in the document *RTEMS -Cache Management For Intel*. On Intel, the -memory region cache management is available only if the paging unit is enabled. -We have used this paging mechanism, with 4Kb page. All the buffers allocated -to store the incoming or outcoming frames, buffer descriptor and also the PCI -address space of the DEC board are located in a memory space with cache disable. - -Concerning the buffers and their descriptors, we have tried to optimize -the memory space in term of allocated page. One buffer has 1520 bytes, one descriptor -has 16 bytes. We have 7 receive buffers and 1 transmit buffer, and for each, -1 descriptor : (7+1)*(1520+16) = 12288 bytes = 12Kb = 3 entire pages. This -allows not to lose too much memory or not to disable cache memory for a page -which contains other data than buffer, which could decrease performance. - -ChorusOs DEC Driver -=================== - -Because ChorusOs is used in several Canon CRF projects, we must provide such -a driver on this OS to ensure compatibility between the RTEMS and ChorusOs developments. -On ChorusOs, a DEC driver source code already exists but only for a PowerPC -target. We plan to port this code (which uses ChorusOs API) on Intel target. -This will allow us to have homogeneous developments. Moreover, the port of the -development performed with ChorusOs environment to RTEMS environment will be -easier for the developers. - -Netboot DEC driver -================== - -We use Netboot tool to load our development from a server to the target via -an ethernet network. Currently, this tool does not support the DEC board. We -plan to port the DEC driver for the Netboot tool. - -But concerning the port of the DEC driver into Netboot, we are faced -with a problem : in RTEMS environment, the DEC driver is interrupt or event -driven, in Netboot environment, it must be used in polling mode. It means that -we will have to re-write some mechanisms of this driver. - -List of Ethernet cards using the DEC chip -========================================= - -Many Ethernet adapter cards use the Tulip chip. Here is a non exhaustive list -of adapters which support this driver : - -- Accton EtherDuo PCI. - -- Accton EN1207 All three media types supported. - -- Adaptec ANA6911/TX 21140-AC. - -- Cogent EM110 21140-A with DP83840 N-Way MII transceiver. - -- Cogent EM400 EM100 with 4 21140 100mbps-only ports + PCI Bridge. - -- Danpex EN-9400P3. - -- D-Link DFE500-Tx 21140-A with DP83840 transceiver. - -- Kingston EtherX KNE100TX 21140AE. - -- Netgear FX310 TX 10/100 21140AE. - -- SMC EtherPower10/100 With DEC21140 and 68836 SYM transceiver. - -- SMC EtherPower10/100 With DEC21140-AC and DP83840 MII transceiver. - Note: The EtherPower II uses the EPIC chip, which requires a different driver. - -- Surecom EP-320X DEC 21140. - -- Thomas Conrad TC5048. - -- Znyx ZX345 21140-A, usually with the DP83840 N-Way MII transciever. Some ZX345 - cards made in 1996 have an ICS 1890 transciver instead. - -- ZNYX ZX348 Two 21140-A chips using ICS 1890 transcievers and either a 21052 - or 21152 bridge. Early versions used National 83840 transcievers, but later - versions are depopulated ZX346 boards. - -- ZNYX ZX351 21140 chip with a Broadcom 100BaseT4 transciever. - -Our DEC driver has not been tested with all these cards, only with the D-Link -DFE500-TX. - -- *[DEC21140 Hardware Manual] DIGITAL, *DIGITAL - Semiconductor 21140A PCI Fast Ethernet LAN Controller - Hardware - Reference Manual**. - -- *[99.TA.0021.M.ER]Emmanuel Raguet,*RTEMS Cache Management For Intel**. - -Command and Variable Index -########################## - -There are currently no Command and Variable Index entries. - -.. COMMENT: @printindex fn - -Concept Index -############# - -There are currently no Concept Index entries. - -.. COMMENT: @printindex cp -- cgit v1.2.3