From 22d213c4846d2d783a8e84cc0b8e067dfe9b1a1e Mon Sep 17 00:00:00 2001 From: Vijay Kumar Banerjee Date: Mon, 1 Mar 2021 09:44:55 -0700 Subject: networking: Rename to legacy networking --- book/index_book.rst | 2 +- legacy-networking/command.rst | 9 + legacy-networking/conf.py | 14 + legacy-networking/dec_21140.rst | 236 +++++++ legacy-networking/index.rst | 31 + legacy-networking/network_servers.rst | 116 +++ legacy-networking/network_task_structure.rst | 33 + legacy-networking/networking_driver.rst | 305 ++++++++ legacy-networking/preface.rst | 38 + legacy-networking/testing_the_driver.rst | 299 ++++++++ legacy-networking/using_networking_rtems_app.rst | 851 +++++++++++++++++++++++ legacy-networking/wscript | 7 + networking/command.rst | 9 - networking/conf.py | 14 - networking/dec_21140.rst | 236 ------- networking/index.rst | 31 - networking/network_servers.rst | 116 --- networking/network_task_structure.rst | 33 - networking/networking_driver.rst | 305 -------- networking/preface.rst | 38 - networking/testing_the_driver.rst | 299 -------- networking/using_networking_rtems_app.rst | 851 ----------------------- networking/wscript | 7 - wscript | 4 +- 24 files changed, 1942 insertions(+), 1942 deletions(-) create mode 100644 legacy-networking/command.rst create mode 100644 legacy-networking/conf.py create mode 100644 legacy-networking/dec_21140.rst create mode 100644 legacy-networking/index.rst create mode 100644 legacy-networking/network_servers.rst create mode 100644 legacy-networking/network_task_structure.rst create mode 100644 legacy-networking/networking_driver.rst create mode 100644 legacy-networking/preface.rst create mode 100644 legacy-networking/testing_the_driver.rst create mode 100644 legacy-networking/using_networking_rtems_app.rst create mode 100644 legacy-networking/wscript delete mode 100644 networking/command.rst delete mode 100644 networking/conf.py delete mode 100644 networking/dec_21140.rst delete mode 100644 networking/index.rst delete mode 100644 networking/network_servers.rst delete mode 100644 networking/network_task_structure.rst delete mode 100644 networking/networking_driver.rst delete mode 100644 networking/preface.rst delete mode 100644 networking/testing_the_driver.rst delete mode 100644 networking/using_networking_rtems_app.rst delete mode 100644 networking/wscript diff --git a/book/index_book.rst b/book/index_book.rst index 8282006..afe15a1 100644 --- a/book/index_book.rst +++ b/book/index_book.rst @@ -23,7 +23,7 @@ Table of Contents cpu_supplement/index.rst develenv/index.rst filesystem/index.rst - networking/index.rst porting/index.rst posix1003_1/index.rst posix_users/index.rst + legacy_networking/index.rst diff --git a/legacy-networking/command.rst b/legacy-networking/command.rst new file mode 100644 index 0000000..269d50d --- /dev/null +++ b/legacy-networking/command.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +Command and Variable Index +########################## + +There are currently no Command and Variable Index entries. + +.. COMMENT: @printindex fn + diff --git a/legacy-networking/conf.py b/legacy-networking/conf.py new file mode 100644 index 0000000..98a06b6 --- /dev/null +++ b/legacy-networking/conf.py @@ -0,0 +1,14 @@ +import sys, os +sys.path.insert(0, os.path.abspath('../common/')) + +from conf import * + +project = "RTEMS Legacy Networking User Manual" + +latex_documents = [ + ('index', + 'legacy-networking.tex', + u'RTEMS Legacy Networking User Manual', + u'RTEMS Documentation Project', + 'manual'), +] diff --git a/legacy-networking/dec_21140.rst b/legacy-networking/dec_21140.rst new file mode 100644 index 0000000..5463b7d --- /dev/null +++ b/legacy-networking/dec_21140.rst @@ -0,0 +1,236 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +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 + + +.. figure ../images/networking/PCIreg.png + :align: center + :alt: PCI Device's Configuration Header Space Format + +.. 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 + + +.. figure:: ../images/networking/recvbd.png + :align: center + :alt: Buffer Descriptor + +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. + +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**. diff --git a/legacy-networking/index.rst b/legacy-networking/index.rst new file mode 100644 index 0000000..b85119d --- /dev/null +++ b/legacy-networking/index.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. include:: ../common/unicode.rst + +.. highlight:: c + +====================================== +RTEMS Legacy Network User Manual (|version|). +====================================== + +.. topic:: Copyrights and License + + | |copy| 2018 Marçal Comajoan Cara + | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR) + + .. include:: ../common/license.rst + +.. include:: ../common/header.rst + +.. toctree:: + :maxdepth: 3 + :numbered: + + preface + network_task_structure + networking_driver + using_networking_rtems_app + testing_the_driver + network_servers + dec_21140 + command diff --git a/legacy-networking/network_servers.rst b/legacy-networking/network_servers.rst new file mode 100644 index 0000000..941a6e2 --- /dev/null +++ b/legacy-networking/network_servers.rst @@ -0,0 +1,116 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: RTEMS Remote Debugger Server Specifications +.. COMMENT: Written by: Emmanuel Raguet + +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-block:: 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-block:: 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 */ + 0, /* Use / as root */ + 1, /* Max. connections */ + 0, /* Infinite idle timeout */ + 0, /* Read-write access */ + 0, /* Ignore login check */ + true /* Say hello */ + }; + +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-block:: c + + int Untar_FromMemory(void *tar_buf, size_t size); + +An example FTP transcript which exercises this hook is: + +.. code-block:: shell + + 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. diff --git a/legacy-networking/network_task_structure.rst b/legacy-networking/network_task_structure.rst new file mode 100644 index 0000000..2ac031b --- /dev/null +++ b/legacy-networking/network_task_structure.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Written by Eric Norum +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +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: + +.. figure:: ../images/networking/networkflow.png + :align: center + :alt: Network Flow + +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. diff --git a/legacy-networking/networking_driver.rst b/legacy-networking/networking_driver.rst new file mode 100644 index 0000000..c161c2b --- /dev/null +++ b/legacy-networking/networking_driver.rst @@ -0,0 +1,305 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Written by Eric Norum +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +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 :file:`bsps/m68k/gen68360/net` 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-block:: makefile + + 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-block:: makefile + + -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 +(:file:`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-block:: 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-block:: 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``. diff --git a/legacy-networking/preface.rst b/legacy-networking/preface.rst new file mode 100644 index 0000000..6926960 --- /dev/null +++ b/legacy-networking/preface.rst @@ -0,0 +1,38 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Written by Eric Norum +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +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 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. diff --git a/legacy-networking/testing_the_driver.rst b/legacy-networking/testing_the_driver.rst new file mode 100644 index 0000000..dbd1163 --- /dev/null +++ b/legacy-networking/testing_the_driver.rst @@ -0,0 +1,299 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Text Written by Jake Janovetz +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +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-block:: shell + + 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-block:: shell + + ************ 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-block:: shell + + ************ 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. diff --git a/legacy-networking/using_networking_rtems_app.rst b/legacy-networking/using_networking_rtems_app.rst new file mode 100644 index 0000000..0d3e245 --- /dev/null +++ b/legacy-networking/using_networking_rtems_app.rst @@ -0,0 +1,851 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Written by Eric Norum +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +Using Networking in an RTEMS Application +######################################## + +Makefile changes +================ + +Including the required managers +------------------------------- + +The FreeBSD networking code requires several RTEMS managers in the application: + +.. code-block:: makefile + + 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-block:: makefile + + 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-block:: c + + #include + +Network Configuration +--------------------- + +The network configuration is specified by declaring and initializing the +``rtems_bsdnet_config`` structure. + +.. code-block:: 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. See + http://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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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. diff --git a/legacy-networking/wscript b/legacy-networking/wscript new file mode 100644 index 0000000..4063cd4 --- /dev/null +++ b/legacy-networking/wscript @@ -0,0 +1,7 @@ +from common.waf import cmd_configure as configure +from common.waf import cmd_build as build +from common.waf import cmd_options as options +from common.waf import spell +from common.waf import cmd_spell +from common.waf import linkcheck +from common.waf import cmd_linkcheck diff --git a/networking/command.rst b/networking/command.rst deleted file mode 100644 index 269d50d..0000000 --- a/networking/command.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -Command and Variable Index -########################## - -There are currently no Command and Variable Index entries. - -.. COMMENT: @printindex fn - diff --git a/networking/conf.py b/networking/conf.py deleted file mode 100644 index 1c129bc..0000000 --- a/networking/conf.py +++ /dev/null @@ -1,14 +0,0 @@ -import sys, os -sys.path.insert(0, os.path.abspath('../common/')) - -from conf import * - -project = "RTEMS Networking User Manual" - -latex_documents = [ - ('index', - 'networking.tex', - u'RTEMS Networking User Manual', - u'RTEMS Documentation Project', - 'manual'), -] diff --git a/networking/dec_21140.rst b/networking/dec_21140.rst deleted file mode 100644 index 5463b7d..0000000 --- a/networking/dec_21140.rst +++ /dev/null @@ -1,236 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -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 - - -.. figure ../images/networking/PCIreg.png - :align: center - :alt: PCI Device's Configuration Header Space Format - -.. 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 - - -.. figure:: ../images/networking/recvbd.png - :align: center - :alt: Buffer Descriptor - -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. - -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**. diff --git a/networking/index.rst b/networking/index.rst deleted file mode 100644 index f56a60d..0000000 --- a/networking/index.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. include:: ../common/unicode.rst - -.. highlight:: c - -====================================== -RTEMS Network User Manual (|version|). -====================================== - -.. topic:: Copyrights and License - - | |copy| 2018 Marçal Comajoan Cara - | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR) - - .. include:: ../common/license.rst - -.. include:: ../common/header.rst - -.. toctree:: - :maxdepth: 3 - :numbered: - - preface - network_task_structure - networking_driver - using_networking_rtems_app - testing_the_driver - network_servers - dec_21140 - command diff --git a/networking/network_servers.rst b/networking/network_servers.rst deleted file mode 100644 index 941a6e2..0000000 --- a/networking/network_servers.rst +++ /dev/null @@ -1,116 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: RTEMS Remote Debugger Server Specifications -.. COMMENT: Written by: Emmanuel Raguet - -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-block:: 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-block:: 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 */ - 0, /* Use / as root */ - 1, /* Max. connections */ - 0, /* Infinite idle timeout */ - 0, /* Read-write access */ - 0, /* Ignore login check */ - true /* Say hello */ - }; - -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-block:: c - - int Untar_FromMemory(void *tar_buf, size_t size); - -An example FTP transcript which exercises this hook is: - -.. code-block:: shell - - 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. diff --git a/networking/network_task_structure.rst b/networking/network_task_structure.rst deleted file mode 100644 index 2ac031b..0000000 --- a/networking/network_task_structure.rst +++ /dev/null @@ -1,33 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: Written by Eric Norum -.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) - -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: - -.. figure:: ../images/networking/networkflow.png - :align: center - :alt: Network Flow - -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. diff --git a/networking/networking_driver.rst b/networking/networking_driver.rst deleted file mode 100644 index c161c2b..0000000 --- a/networking/networking_driver.rst +++ /dev/null @@ -1,305 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: Written by Eric Norum -.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) - -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 :file:`bsps/m68k/gen68360/net` 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-block:: makefile - - 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-block:: makefile - - -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 -(:file:`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-block:: 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-block:: 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``. diff --git a/networking/preface.rst b/networking/preface.rst deleted file mode 100644 index 6926960..0000000 --- a/networking/preface.rst +++ /dev/null @@ -1,38 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: Written by Eric Norum -.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) - -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 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. diff --git a/networking/testing_the_driver.rst b/networking/testing_the_driver.rst deleted file mode 100644 index dbd1163..0000000 --- a/networking/testing_the_driver.rst +++ /dev/null @@ -1,299 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: Text Written by Jake Janovetz -.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) - -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-block:: shell - - 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-block:: shell - - ************ 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-block:: shell - - ************ 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. diff --git a/networking/using_networking_rtems_app.rst b/networking/using_networking_rtems_app.rst deleted file mode 100644 index 0d3e245..0000000 --- a/networking/using_networking_rtems_app.rst +++ /dev/null @@ -1,851 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. COMMENT: Written by Eric Norum -.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) - -Using Networking in an RTEMS Application -######################################## - -Makefile changes -================ - -Including the required managers -------------------------------- - -The FreeBSD networking code requires several RTEMS managers in the application: - -.. code-block:: makefile - - 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-block:: makefile - - 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-block:: c - - #include - -Network Configuration ---------------------- - -The network configuration is specified by declaring and initializing the -``rtems_bsdnet_config`` structure. - -.. code-block:: 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. See - http://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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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-block:: 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. diff --git a/networking/wscript b/networking/wscript deleted file mode 100644 index 4063cd4..0000000 --- a/networking/wscript +++ /dev/null @@ -1,7 +0,0 @@ -from common.waf import cmd_configure as configure -from common.waf import cmd_build as build -from common.waf import cmd_options as options -from common.waf import spell -from common.waf import cmd_spell -from common.waf import linkcheck -from common.waf import cmd_linkcheck diff --git a/wscript b/wscript index ce644f8..0b1c368 100644 --- a/wscript +++ b/wscript @@ -32,11 +32,11 @@ build_all = ['user', 'posix-compliance', 'eng', 'filesystem', - 'networking', 'shell', 'cpu-supplement', 'develenv', - 'eclipse'] + 'eclipse', + 'legacy-networking'] building = build_all -- cgit v1.2.3