Reorganized firmware/ subdirectory (x300->usrp3, zpu->usrp2)

6 files changed, 0 insertions, 1091 deletions

diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/FILES b/firmware/x300/lwip/lwip-1.3.1/doc/FILES
deleted file mode 100644
index 05d356f4f..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/FILES
+++ /dev/null
@@ -1,6 +0,0 @@
-savannah.txt   - How to obtain the current development source code.
-contrib.txt    - How to contribute to lwIP as a developer.
-rawapi.txt     - The documentation for the core API of lwIP.
-                 Also provides an overview about the other APIs and multithreading.
-snmp_agent.txt - The documentation for the lwIP SNMP agent.
-sys_arch.txt   - The documentation for a system abstraction layer of lwIP.
diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/contrib.txt b/firmware/x300/lwip/lwip-1.3.1/doc/contrib.txt
deleted file mode 100644
index 39596fca3..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/contrib.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-1 Introduction
-
-This document describes some guidelines for people participating
-in lwIP development.
-
-2 How to contribute to lwIP
-
-Here is a short list of suggestions to anybody working with lwIP and 
-trying to contribute bug reports, fixes, enhancements, platform ports etc.
-First of all as you may already know lwIP is a volunteer project so feedback
-to fixes or questions might often come late. Hopefully the bug and patch tracking 
-features of Savannah help us not lose users' input.
-
-2.1 Source code style:
-
-1. do not use tabs.
-2. indentation is two spaces per level (i.e. per tab).
-3. end debug messages with a trailing newline (\n).
-4. one space between keyword and opening bracket.
-5. no space between function and opening bracket.
-6. one space and no newline before opening curly braces of a block.
-7. closing curly brace on a single line.
-8. spaces surrounding assignment and comparisons.
-9. don't initialize static and/or global variables to zero, the compiler takes care of that.
-10. use current source code style as further reference.
-
-2.2 Source code documentation style:
-
-1. JavaDoc compliant and Doxygen compatible.
-2. Function documentation above functions in .c files, not .h files.
-   (This forces you to synchronize documentation and implementation.)
-3. Use current documentation style as further reference.
- 
-2.3 Bug reports and patches:
-
-1. Make sure you are reporting bugs or send patches against the latest
-   sources. (From the latest release and/or the current CVS sources.)
-2. If you think you found a bug make sure it's not already filed in the
-   bugtracker at Savannah.
-3. If you have a fix put the patch on Savannah. If it is a patch that affects
-   both core and arch specific stuff please separate them so that the core can
-   be applied separately while leaving the other patch 'open'. The prefered way
-   is to NOT touch archs you can't test and let maintainers take care of them.
-   This is a good way to see if they are used at all - the same goes for unix
-   netifs except tapif.
-4. Do not file a bug and post a fix to it to the patch area. Either a bug report
-   or a patch will be enough.
-   If you correct an existing bug then attach the patch to the bug rather than creating a new entry in the patch area.
-5. Trivial patches (compiler warning, indentation and spelling fixes or anything obvious which takes a line or two)
-   can go to the lwip-users list. This is still the fastest way of interaction and the list is not so crowded
-   as to allow for loss of fixes. Putting bugs on Savannah and subsequently closing them is too much an overhead
-   for reporting a compiler warning fix.
-6. Patches should be specific to a single change or to related changes.Do not mix bugfixes with spelling and other
-   trivial fixes unless the bugfix is trivial too.Do not reorganize code and rename identifiers in the same patch you
-   change behaviour if not necessary.A patch is easier to read and understand if it's to the point and short than
-   if it's not to the point and long :) so the chances for it to be applied are greater. 
-
-2.4 Platform porters:
-
-1. If you have ported lwIP to a platform (an OS, a uC/processor or a combination of these) and
-   you think it could benefit others[1] you might want discuss this on the mailing list. You
-   can also ask for CVS access to submit and maintain your port in the contrib CVS module.
-   
\ No newline at end of file
diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/rawapi.txt b/firmware/x300/lwip/lwip-1.3.1/doc/rawapi.txt
deleted file mode 100644
index 8eec6e786..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/rawapi.txt
+++ /dev/null
@@ -1,478 +0,0 @@
-Raw TCP/IP interface for lwIP
-
-Authors: Adam Dunkels, Leon Woestenberg, Christiaan Simons
-
-lwIP provides three Application Program's Interfaces (APIs) for programs
-to use for communication with the TCP/IP code:
-* low-level "core" / "callback" or "raw" API.
-* higher-level "sequential" API.
-* BSD-style socket API.
-
-The sequential API provides a way for ordinary, sequential, programs
-to use the lwIP stack. It is quite similar to the BSD socket API. The
-model of execution is based on the blocking open-read-write-close
-paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP
-code and the application program must reside in different execution
-contexts (threads).
-
-The socket API is a compatibility API for existing applications,
-currently it is built on top of the sequential API. It is meant to
-provide all functions needed to run socket API applications running
-on other platforms (e.g. unix / windows etc.). However, due to limitations
-in the specification of this API, there might be incompatibilities
-that require small modifications of existing programs.
-
-** Threading
-
-lwIP started targeting single-threaded environments. When adding multi-
-threading support, instead of making the core thread-safe, another
-approach was chosen: there is one main thread running the lwIP core
-(also known as the "tcpip_thread"). The raw API may only be used from
-this thread! Application threads using the sequential- or socket API
-communicate with this main thread through message passing.
-
-      As such, the list of functions that may be called from
-      other threads or an ISR is very limited! Only functions
-      from these API header files are thread-safe:
-      - api.h
-      - netbuf.h
-      - netdb.h
-      - netifapi.h
-      - sockets.h
-      - sys.h
-
-      Additionaly, memory (de-)allocation functions may be
-      called from multiple threads (not ISR!) with NO_SYS=0
-      since they are protected by SYS_LIGHTWEIGHT_PROT and/or
-      semaphores.
-
-      Only since 1.3.0, if SYS_LIGHTWEIGHT_PROT is set to 1
-      and LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is set to 1,
-      pbuf_free() may also be called from another thread or
-      an ISR (since only then, mem_free - for PBUF_RAM - may
-      be called from an ISR: otherwise, the HEAP is only
-      protected by semaphores).
-      
-
-** The remainder of this document discusses the "raw" API. **
-
-The raw TCP/IP interface allows the application program to integrate
-better with the TCP/IP code. Program execution is event based by
-having callback functions being called from within the TCP/IP
-code. The TCP/IP code and the application program both run in the same
-thread. The sequential API has a much higher overhead and is not very
-well suited for small systems since it forces a multithreaded paradigm
-on the application.
-
-The raw TCP/IP interface is not only faster in terms of code execution
-time but is also less memory intensive. The drawback is that program
-development is somewhat harder and application programs written for
-the raw TCP/IP interface are more difficult to understand. Still, this
-is the preferred way of writing applications that should be small in
-code size and memory usage.
-
-Both APIs can be used simultaneously by different application
-programs. In fact, the sequential API is implemented as an application
-program using the raw TCP/IP interface.
-
---- Callbacks
-
-Program execution is driven by callbacks. Each callback is an ordinary
-C function that is called from within the TCP/IP code. Every callback
-function is passed the current TCP or UDP connection state as an
-argument. Also, in order to be able to keep program specific state,
-the callback functions are called with a program specified argument
-that is independent of the TCP/IP state.
-
-The function for setting the application connection state is:
-
-- void tcp_arg(struct tcp_pcb *pcb, void *arg)
-
-  Specifies the program specific state that should be passed to all
-  other callback functions. The "pcb" argument is the current TCP
-  connection control block, and the "arg" argument is the argument
-  that will be passed to the callbacks.
-
-  
---- TCP connection setup
-
-The functions used for setting up connections is similar to that of
-the sequential API and of the BSD socket API. A new TCP connection
-identifier (i.e., a protocol control block - PCB) is created with the
-tcp_new() function. This PCB can then be either set to listen for new
-incoming connections or be explicitly connected to another host.
-
-- struct tcp_pcb *tcp_new(void)
-
-  Creates a new connection identifier (PCB). If memory is not
-  available for creating the new pcb, NULL is returned.
-
-- err_t tcp_bind(struct tcp_pcb *pcb, struct ip_addr *ipaddr,
-                 u16_t port)
-
-  Binds the pcb to a local IP address and port number. The IP address
-  can be specified as IP_ADDR_ANY in order to bind the connection to
-  all local IP addresses.
-
-  If another connection is bound to the same port, the function will
-  return ERR_USE, otherwise ERR_OK is returned.
-
-- struct tcp_pcb *tcp_listen(struct tcp_pcb *pcb)
-
-  Commands a pcb to start listening for incoming connections. When an
-  incoming connection is accepted, the function specified with the
-  tcp_accept() function will be called. The pcb will have to be bound
-  to a local port with the tcp_bind() function.
-
-  The tcp_listen() function returns a new connection identifier, and
-  the one passed as an argument to the function will be
-  deallocated. The reason for this behavior is that less memory is
-  needed for a connection that is listening, so tcp_listen() will
-  reclaim the memory needed for the original connection and allocate a
-  new smaller memory block for the listening connection.
-
-  tcp_listen() may return NULL if no memory was available for the
-  listening connection. If so, the memory associated with the pcb
-  passed as an argument to tcp_listen() will not be deallocated.
-
-- struct tcp_pcb *tcp_listen_with_backlog(struct tcp_pcb *pcb, u8_t backlog)
-
-  Same as tcp_listen, but limits the number of outstanding connections
-  in the listen queue to the value specified by the backlog argument.
-  To use it, your need to set TCP_LISTEN_BACKLOG=1 in your lwipopts.h.
-
-- void tcp_accepted(struct tcp_pcb *pcb)
-
-  Inform lwIP that an incoming connection has been accepted. This would
-  usually be called from the accept callback. This allows lwIP to perform
-  housekeeping tasks, such as allowing further incoming connections to be
-  queued in the listen backlog.
-
-- void tcp_accept(struct tcp_pcb *pcb,
-                  err_t (* accept)(void *arg, struct tcp_pcb *newpcb,
-                                   err_t err))
-
-  Specified the callback function that should be called when a new
-  connection arrives on a listening connection.
-      
-- err_t tcp_connect(struct tcp_pcb *pcb, struct ip_addr *ipaddr,
-                    u16_t port, err_t (* connected)(void *arg,
-                                                    struct tcp_pcb *tpcb,
-                                                    err_t err));
-
-  Sets up the pcb to connect to the remote host and sends the
-  initial SYN segment which opens the connection. 
-
-  The tcp_connect() function returns immediately; it does not wait for
-  the connection to be properly setup. Instead, it will call the
-  function specified as the fourth argument (the "connected" argument)
-  when the connection is established. If the connection could not be
-  properly established, either because the other host refused the
-  connection or because the other host didn't answer, the "err"
-  callback function of this pcb (registered with tcp_err, see below)
-  will be called.
-
-  The tcp_connect() function can return ERR_MEM if no memory is
-  available for enqueueing the SYN segment. If the SYN indeed was
-  enqueued successfully, the tcp_connect() function returns ERR_OK.
-
-  
---- Sending TCP data
-
-TCP data is sent by enqueueing the data with a call to
-tcp_write(). When the data is successfully transmitted to the remote
-host, the application will be notified with a call to a specified
-callback function.
-
-- err_t tcp_write(struct tcp_pcb *pcb, void *dataptr, u16_t len,
-                  u8_t copy)
-
-  Enqueues the data pointed to by the argument dataptr. The length of
-  the data is passed as the len parameter. The copy argument is either
-  0 or 1 and indicates whether the new memory should be allocated for
-  the data to be copied into. If the argument is 0, no new memory
-  should be allocated and the data should only be referenced by
-  pointer.
-
-  The tcp_write() function will fail and return ERR_MEM if the length
-  of the data exceeds the current send buffer size or if the length of
-  the queue of outgoing segment is larger than the upper limit defined
-  in lwipopts.h. The number of bytes available in the output queue can
-  be retrieved with the tcp_sndbuf() function.
-
-  The proper way to use this function is to call the function with at
-  most tcp_sndbuf() bytes of data. If the function returns ERR_MEM,
-  the application should wait until some of the currently enqueued
-  data has been successfully received by the other host and try again.
-
-- void tcp_sent(struct tcp_pcb *pcb,
-                err_t (* sent)(void *arg, struct tcp_pcb *tpcb,
-                u16_t len))
-
-  Specifies the callback function that should be called when data has
-  successfully been received (i.e., acknowledged) by the remote
-  host. The len argument passed to the callback function gives the
-  amount bytes that was acknowledged by the last acknowledgment.
-
-  
---- Receiving TCP data
-
-TCP data reception is callback based - an application specified
-callback function is called when new data arrives. When the
-application has taken the data, it has to call the tcp_recved()
-function to indicate that TCP can advertise increase the receive
-window.
-
-- void tcp_recv(struct tcp_pcb *pcb,
-                err_t (* recv)(void *arg, struct tcp_pcb *tpcb,
-                               struct pbuf *p, err_t err))
-
-  Sets the callback function that will be called when new data
-  arrives. The callback function will be passed a NULL pbuf to
-  indicate that the remote host has closed the connection. If
-  there are no errors and the callback function is to return
-  ERR_OK, then it must free the pbuf. Otherwise, it must not
-  free the pbuf so that lwIP core code can store it.
-
-- void tcp_recved(struct tcp_pcb *pcb, u16_t len)
-
-  Must be called when the application has received the data. The len
-  argument indicates the length of the received data.
-    
-
---- Application polling
-
-When a connection is idle (i.e., no data is either transmitted or
-received), lwIP will repeatedly poll the application by calling a
-specified callback function. This can be used either as a watchdog
-timer for killing connections that have stayed idle for too long, or
-as a method of waiting for memory to become available. For instance,
-if a call to tcp_write() has failed because memory wasn't available,
-the application may use the polling functionality to call tcp_write()
-again when the connection has been idle for a while.
-
-- void tcp_poll(struct tcp_pcb *pcb, u8_t interval,
-                err_t (* poll)(void *arg, struct tcp_pcb *tpcb))
-
-  Specifies the polling interval and the callback function that should
-  be called to poll the application. The interval is specified in
-  number of TCP coarse grained timer shots, which typically occurs
-  twice a second. An interval of 10 means that the application would
-  be polled every 5 seconds.
-
-
---- Closing and aborting connections
-
-- err_t tcp_close(struct tcp_pcb *pcb)
-
-  Closes the connection. The function may return ERR_MEM if no memory
-  was available for closing the connection. If so, the application
-  should wait and try again either by using the acknowledgment
-  callback or the polling functionality. If the close succeeds, the
-  function returns ERR_OK.
-
-  The pcb is deallocated by the TCP code after a call to tcp_close(). 
-
-- void tcp_abort(struct tcp_pcb *pcb)
-
-  Aborts the connection by sending a RST (reset) segment to the remote
-  host. The pcb is deallocated. This function never fails.
-
-If a connection is aborted because of an error, the application is
-alerted of this event by the err callback. Errors that might abort a
-connection are when there is a shortage of memory. The callback
-function to be called is set using the tcp_err() function.
-
-- void tcp_err(struct tcp_pcb *pcb, void (* err)(void *arg,
-       err_t err))
-
-  The error callback function does not get the pcb passed to it as a
-  parameter since the pcb may already have been deallocated.
-
-
---- Lower layer TCP interface
-
-TCP provides a simple interface to the lower layers of the
-system. During system initialization, the function tcp_init() has
-to be called before any other TCP function is called. When the system
-is running, the two timer functions tcp_fasttmr() and tcp_slowtmr()
-must be called with regular intervals. The tcp_fasttmr() should be
-called every TCP_FAST_INTERVAL milliseconds (defined in tcp.h) and
-tcp_slowtmr() should be called every TCP_SLOW_INTERVAL milliseconds. 
-
-
---- UDP interface
-
-The UDP interface is similar to that of TCP, but due to the lower
-level of complexity of UDP, the interface is significantly simpler.
-
-- struct udp_pcb *udp_new(void)
-
-  Creates a new UDP pcb which can be used for UDP communication. The
-  pcb is not active until it has either been bound to a local address
-  or connected to a remote address.
-
-- void udp_remove(struct udp_pcb *pcb)
-
-  Removes and deallocates the pcb.  
-  
-- err_t udp_bind(struct udp_pcb *pcb, struct ip_addr *ipaddr,
-                 u16_t port)
-
-  Binds the pcb to a local address. The IP-address argument "ipaddr"
-  can be IP_ADDR_ANY to indicate that it should listen to any local IP
-  address. The function currently always return ERR_OK.
-
-- err_t udp_connect(struct udp_pcb *pcb, struct ip_addr *ipaddr,
-                    u16_t port)
-
-  Sets the remote end of the pcb. This function does not generate any
-  network traffic, but only set the remote address of the pcb.
-
-- err_t udp_disconnect(struct udp_pcb *pcb)
-
-  Remove the remote end of the pcb. This function does not generate
-  any network traffic, but only removes the remote address of the pcb.
-
-- err_t udp_send(struct udp_pcb *pcb, struct pbuf *p)
-
-  Sends the pbuf p. The pbuf is not deallocated.
-
-- void udp_recv(struct udp_pcb *pcb,
-                void (* recv)(void *arg, struct udp_pcb *upcb,
-                                         struct pbuf *p,
-                                         struct ip_addr *addr,
-                                         u16_t port),
-                              void *recv_arg)
-
-  Specifies a callback function that should be called when a UDP
-  datagram is received.
-  
-
---- System initalization
-
-A truly complete and generic sequence for initializing the lwip stack
-cannot be given because it depends on the build configuration (lwipopts.h)
-and additional initializations for your runtime environment (e.g. timers).
-
-We can give you some idea on how to proceed when using the raw API.
-We assume a configuration using a single Ethernet netif and the
-UDP and TCP transport layers, IPv4 and the DHCP client.
-
-Call these functions in the order of appearance:
-
-- stats_init()
-
-  Clears the structure where runtime statistics are gathered.
-
-- sys_init()
-  
-  Not of much use since we set the NO_SYS 1 option in lwipopts.h,
-  to be called for easy configuration changes.
-
-- mem_init()
-
-  Initializes the dynamic memory heap defined by MEM_SIZE.
-
-- memp_init()
-
-  Initializes the memory pools defined by MEMP_NUM_x.
-
-- pbuf_init()
-
-  Initializes the pbuf memory pool defined by PBUF_POOL_SIZE.
-  
-- etharp_init()
-
-  Initializes the ARP table and queue.
-  Note: you must call etharp_tmr at a ARP_TMR_INTERVAL (5 seconds) regular interval
-  after this initialization.
-
-- ip_init()
-
-  Doesn't do much, it should be called to handle future changes.
-
-- udp_init()
-
-  Clears the UDP PCB list.
-
-- tcp_init()
-
-  Clears the TCP PCB list and clears some internal TCP timers.
-  Note: you must call tcp_fasttmr() and tcp_slowtmr() at the
-  predefined regular intervals after this initialization. 
-  
-- netif_add(struct netif *netif, struct ip_addr *ipaddr,
-            struct ip_addr *netmask, struct ip_addr *gw,
-            void *state, err_t (* init)(struct netif *netif),
-            err_t (* input)(struct pbuf *p, struct netif *netif))
-
-  Adds your network interface to the netif_list. Allocate a struct
-  netif and pass a pointer to this structure as the first argument.
-  Give pointers to cleared ip_addr structures when using DHCP,
-  or fill them with sane numbers otherwise. The state pointer may be NULL.
-
-  The init function pointer must point to a initialization function for
-  your ethernet netif interface. The following code illustrates it's use.
-  
-  err_t netif_if_init(struct netif *netif)
-  {
-    u8_t i;
-    
-    for(i = 0; i < ETHARP_HWADDR_LEN; i++) netif->hwaddr[i] = some_eth_addr[i];
-    init_my_eth_device();
-    return ERR_OK;
-  }
-  
-  For ethernet drivers, the input function pointer must point to the lwip
-  function ethernet_input() declared in "netif/etharp.h". Other drivers
-  must use ip_input() declared in "lwip/ip.h".
-  
-- netif_set_default(struct netif *netif)
-
-  Registers the default network interface.
-
-- netif_set_up(struct netif *netif)
-
-  When the netif is fully configured this function must be called.
-
-- dhcp_start(struct netif *netif)
-
-  Creates a new DHCP client for this interface on the first call.
-  Note: you must call dhcp_fine_tmr() and dhcp_coarse_tmr() at
-  the predefined regular intervals after starting the client.
-  
-  You can peek in the netif->dhcp struct for the actual DHCP status.
-
-
---- Optimalization hints
-
-The first thing you want to optimize is the lwip_standard_checksum()
-routine from src/core/inet.c. You can override this standard
-function with the #define LWIP_CHKSUM <your_checksum_routine>.
-
-There are C examples given in inet.c or you might want to
-craft an assembly function for this. RFC1071 is a good
-introduction to this subject.
-
-Other significant improvements can be made by supplying
-assembly or inline replacements for htons() and htonl()
-if you're using a little-endian architecture.
-#define LWIP_PLATFORM_BYTESWAP 1
-#define LWIP_PLATFORM_HTONS(x) <your_htons>
-#define LWIP_PLATFORM_HTONL(x) <your_htonl>
-
-Check your network interface driver if it reads at
-a higher speed than the maximum wire-speed. If the
-hardware isn't serviced frequently and fast enough
-buffer overflows are likely to occur.
-
-E.g. when using the cs8900 driver, call cs8900if_service(ethif)
-as frequently as possible. When using an RTOS let the cs8900 interrupt
-wake a high priority task that services your driver using a binary
-semaphore or event flag. Some drivers might allow additional tuning
-to match your application and network.
-
-For a production release it is recommended to set LWIP_STATS to 0.
-Note that speed performance isn't influenced much by simply setting
-high values to the memory options.
diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/savannah.txt b/firmware/x300/lwip/lwip-1.3.1/doc/savannah.txt
deleted file mode 100644
index 409905b10..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/savannah.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-Daily Use Guide for using Savannah for lwIP
-
-Table of Contents:
-
-1 - Obtaining lwIP from the CVS repository
-2 - Committers/developers CVS access using SSH (to be written)
-3 - Merging from DEVEL branch to main trunk (stable branch)
-4 - How to release lwIP
-
-
-
-1 Obtaining lwIP from the CVS repository
-----------------------------------------
-
-To perform an anonymous CVS checkout of the main trunk (this is where
-bug fixes and incremental enhancements occur), do this:
-
-cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/lwip checkout lwip
- 
-Or, obtain a stable branch (updated with bug fixes only) as follows:
-cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/lwip checkout \
-  -r STABLE-0_7 -d lwip-0.7 lwip
-
-Or, obtain a specific (fixed) release as follows:
-cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/lwip checkout \
-  -r STABLE-0_7_0 -d lwip-0.7.0 lwip
-
-3 Committers/developers CVS access using SSH
---------------------------------------------
-
-The Savannah server uses SSH (Secure Shell) protocol 2 authentication and encryption.
-As such, CVS commits to the server occur through a SSH tunnel for project members.
-To create a SSH2 key pair in UNIX-like environments, do this:
-
-ssh-keygen -t dsa
-
-Under Windows, a recommended SSH client is "PuTTY", freely available with good
-documentation and a graphic user interface. Use its key generator.
-
-Now paste the id_dsa.pub contents into your Savannah account public key list. Wait
-a while so that Savannah can update its configuration (This can take minutes).
-
-Try to login using SSH:
-
-ssh -v your_login@cvs.sv.gnu.org
-
-If it tells you:
-
-Authenticating with public key "your_key_name"...
-Server refused to allocate pty
-
-then you could login; Savannah refuses to give you a shell - which is OK, as we
-are allowed to use SSH for CVS only. Now, you should be able to do this:
-
-export CVS_RSH=ssh
-cvs -z3 -d:ext:your_login@cvs.sv.gnu.org:/sources/lwip co lwip
- 
-after which you can edit your local files with bug fixes or new features and
-commit them. Make sure you know what you are doing when using CVS to make
-changes on the repository. If in doubt, ask on the lwip-members mailing list.
-
-(If SSH asks about authenticity of the host, you can check the key
- fingerprint against http://savannah.nongnu.org/cvs/?group=lwip)
-
-
-3 Merging from DEVEL branch to main trunk (stable)
---------------------------------------------------
-
-Merging is a delicate process in CVS and requires the
-following disciplined steps in order to prevent conflicts
-in the future. Conflicts can be hard to solve!
-
-Merging from branch A to branch B requires that the A branch
-has a tag indicating the previous merger. This tag is called
-'merged_from_A_to_B'. After merging, the tag is moved in the
-A branch to remember this merger for future merge actions.
-
-IMPORTANT: AFTER COMMITTING A SUCCESFUL MERGE IN THE
-REPOSITORY, THE TAG MUST BE SET ON THE SOURCE BRANCH OF THE
-MERGE ACTION (REPLACING EXISTING TAGS WITH THE SAME NAME).
-
-Merge all changes in DEVEL since our last merge to main:
-
-In the working copy of the main trunk:
-cvs update -P -jmerged_from_DEVEL_to_main -jDEVEL 
-
-(This will apply the changes between 'merged_from_DEVEL_to_main'
-and 'DEVEL' to your work set of files)
-
-We can now commit the merge result.
-cvs commit -R -m "Merged from DEVEL to main." 
-
-If this worked out OK, we now move the tag in the DEVEL branch
-to this merge point, so we can use this point for future merges:
-
-cvs rtag -F -r DEVEL merged_from_DEVEL_to_main lwip 
-
-4 How to release lwIP
----------------------
-
-First, checkout a clean copy of the branch to be released. Tag this set with
-tag name "STABLE-0_6_3". (I use release number 0.6.3 throughout this example).
-
-Login CVS using pserver authentication, then export a clean copy of the
-tagged tree. Export is similar to a checkout, except that the CVS metadata
-is not created locally. 
-
-export CVS_RSH=ssh
-cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/lwip checkout \
-  -r STABLE-0_6_3 -d lwip-0.6.3 lwip
-
-Archive this directory using tar, gzip'd, bzip2'd and zip'd.
-
-tar czvf lwip-0.6.3.tar.gz lwip-0.6.3
-tar cjvf lwip-0.6.3.tar.bz2 lwip-0.6.3
-zip -r lwip-0.6.3.zip lwip-0.6.3
-
-Now, sign the archives with a detached GPG binary signature as follows:
-
-gpg -b lwip-0.6.3.tar.gz
-gpg -b lwip-0.6.3.tar.bz2
-gpg -b lwip-0.6.3.zip
-
-Upload these files using anonymous FTP:
-ncftp ftp://savannah.gnu.org/incoming/savannah/lwip
-
-ncftp>mput *0.6.3.*
-
-Additionally, you may post a news item on Savannah, like this:
-
-A new 0.6.3 release is now available here:
-http://savannah.nongnu.org/files/?group=lwip&highlight=0.6.3
-
-You will have to submit this via the user News interface, then approve
-this via the Administrator News interface.
\ No newline at end of file
diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/snmp_agent.txt b/firmware/x300/lwip/lwip-1.3.1/doc/snmp_agent.txt
deleted file mode 100644
index 9b58616a6..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/snmp_agent.txt
+++ /dev/null
@@ -1,181 +0,0 @@
-SNMPv1 agent for lwIP
-
-Author: Christiaan Simons
-
-This is a brief introduction how to use and configure the SNMP agent.
-Note the agent uses the raw-API UDP interface so you may also want to
-read rawapi.txt to gain a better understanding of the SNMP message handling.
-
-0 Agent Capabilities
-====================
-
-SNMPv1 per RFC1157
-  This is an old(er) standard but is still widely supported.
-  For SNMPv2c and v3 have a greater complexity and need many
-  more lines of code. IMHO this breaks the idea of "lightweight IP".
-
-  Note the S in SNMP stands for "Simple". Note that "Simple" is
-  relative. SNMP is simple compared to the complex ISO network
-  management protocols CMIP (Common Management Information Protocol)
-  and CMOT (CMip Over Tcp).
-
-MIB II per RFC1213
-  The standard lwIP stack management information base.
-  This is a required MIB, so this is always enabled.
-  When builing lwIP without TCP, the mib-2.tcp group is omitted.
-  The groups EGP, CMOT and transmission are disabled by default.
-  
-  Most mib-2 objects are not writable except:
-  sysName, sysLocation, sysContact, snmpEnableAuthenTraps.
-  Writing to or changing the ARP and IP address and route
-  tables is not possible.
- 
-  Note lwIP has a very limited notion of IP routing. It currently
-  doen't have a route table and doesn't have a notion of the U,G,H flags.
-  Instead lwIP uses the interface list with only one default interface
-  acting as a single gateway interface (G) for the default route.
-
-  The agent returns a "virtual table" with the default route 0.0.0.0
-  for the default interface and network routes (no H) for each
-  network interface in the netif_list.
-  All routes are considered to be up (U).
-
-Loading additional MIBs
-  MIBs can only be added in compile-time, not in run-time.
-  There is no MIB compiler thus additional MIBs must be hand coded.
-
-Large SNMP message support
-  The packet decoding and encoding routines are designed
-  to use pbuf-chains. Larger payloads then the minimum
-  SNMP requirement of 484 octets are supported if the 
-  PBUF_POOL_SIZE and IP_REASS_BUFSIZE are set to match your
-  local requirement.
-
-1 Building the Agent
-====================
-
-First of all you'll need to add the following define
-to your local lwipopts.h:
-
-#define LWIP_SNMP               1
-
-and add the source files in lwip/src/core/snmp
-and some snmp headers in lwip/src/include/lwip to your makefile.
-
-Note you'll might need to adapt you network driver to update
-the mib2 variables for your interface.
-
-2 Running the Agent
-===================
-
-The following function calls must be made in your program to
-actually get the SNMP agent running.
-
-Before starting the agent you should supply pointers
-to non-volatile memory for sysContact, sysLocation,
-and snmpEnableAuthenTraps. You can do this by calling
-
-snmp_set_syscontact()
-snmp_set_syslocation()
-snmp_set_snmpenableauthentraps()
-
-Additionally you may want to set
-
-snmp_set_sysdescr()
-snmp_set_sysobjid() (if you have a private MIB)
-snmp_set_sysname()
-
-Also before starting the agent you need to setup
-one or more trap destinations using these calls:
-
-snmp_trap_dst_enable();
-snmp_trap_dst_ip_set();
-
-In the lwIP initialisation sequence call snmp_init() just after
-the call to udp_init().
-
-Exactly every 10 msec the SNMP uptime timestamp must be updated with
-snmp_inc_sysuptime(). You should call this from a timer interrupt
-or a timer signal handler depending on your runtime environment.
-
-An alternative way to update the SNMP uptime timestamp is to do a call like
-snmp_add_sysuptime(100) each 1000ms (which is bigger "step", but call to
-a lower frequency). Another one is to not call snmp_inc_sysuptime() or
-snmp_add_sysuptime(), and to define the SNMP_GET_SYSUPTIME(sysuptime) macro.
-This one is undefined by default in mib2.c. SNMP_GET_SYSUPTIME is called inside
-snmp_get_sysuptime(u32_t *value), and enable to change "sysuptime" value only
-when it's queried (any function which need "sysuptime" have to call
-snmp_get_sysuptime).
-
-
-3 Private MIBs
-==============
-
-If want to extend the agent with your own private MIB you'll need to
-add the following define to your local lwipopts.h:
-
-#define SNMP_PRIVATE_MIB        1
-
-You must provide the private_mib.h and associated files yourself.
-Note we don't have a "MIB compiler" that generates C source from a MIB,
-so you're required to do some serious coding if you enable this!
-
-Note the lwIP enterprise ID (26381) is assigned to the lwIP project,
-ALL OBJECT IDENTIFIERS LIVING UNDER THIS ID ARE ASSIGNED BY THE lwIP
-MAINTAINERS!
-
-If you need to create your own private MIB you'll need
-to apply for your own enterprise ID with IANA: http://www.iana.org/numbers.html 
-
-You can set it by passing a struct snmp_obj_id to the agent
-using snmp_set_sysobjid(&my_object_id), just before snmp_init().
-
-Note the object identifiers for thes MIB-2 and your private MIB
-tree must be kept in sorted ascending (lexicographical) order.
-This to ensure correct getnext operation.
-
-An example for a private MIB is part of the "minimal Unix" project:
-contrib/ports/unix/proj/minimal/lwip_prvmib.c
-
-The next chapter gives a more detailed description of the
-MIB-2 tree and the optional private MIB.
-
-4 The Gory Details
-==================
-
-4.0 Object identifiers and the MIB tree.
-
-We have three distinct parts for all object identifiers:
-
-The prefix
-  .iso.org.dod.internet
-
-the middle part 
-  .mgmt.mib-2.ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress
-
-and the index part
-  .1.192.168.0.1
-
-Objects located above the .internet hierarchy aren't supported.
-Currently only the .mgmt sub-tree is available and
-when the SNMP_PRIVATE_MIB is enabled the .private tree
-becomes available too.
-
-Object identifiers from incoming requests are checked
-for a matching prefix, middle part and index part
-or are expanded(*) for GetNext requests with short
-or inexisting names in the request.
-(* we call this "expansion" but this also
-resembles the "auto-completion" operation)
-
-The middle part is usually located in ROM (const)
-to preserve precious RAM on small microcontrollers.
-However RAM location is possible for an dynamically
-changing private tree.
-
-The index part is handled by functions which in
-turn use dynamically allocated index trees from RAM.
-These trees are updated by e.g. the etharp code
-when new entries are made or removed form the ARP cache.
-
-/** @todo more gory details */
diff --git a/firmware/x300/lwip/lwip-1.3.1/doc/sys_arch.txt b/firmware/x300/lwip/lwip-1.3.1/doc/sys_arch.txt
deleted file mode 100644
index 66310a91e..000000000
--- a/firmware/x300/lwip/lwip-1.3.1/doc/sys_arch.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-sys_arch interface for lwIP 0.6++
-
-Author: Adam Dunkels
-
-The operating system emulation layer provides a common interface
-between the lwIP code and the underlying operating system kernel. The
-general idea is that porting lwIP to new architectures requires only
-small changes to a few header files and a new sys_arch
-implementation. It is also possible to do a sys_arch implementation
-that does not rely on any underlying operating system.
-
-The sys_arch provides semaphores and mailboxes to lwIP. For the full
-lwIP functionality, multiple threads support can be implemented in the
-sys_arch, but this is not required for the basic lwIP
-functionality. Previous versions of lwIP required the sys_arch to
-implement timer scheduling as well but as of lwIP 0.5 this is
-implemented in a higher layer.
-
-In addition to the source file providing the functionality of sys_arch,
-the OS emulation layer must provide several header files defining
-macros used throughout lwip.  The files required and the macros they
-must define are listed below the sys_arch description.
-
-Semaphores can be either counting or binary - lwIP works with both
-kinds. Mailboxes are used for message passing and can be implemented
-either as a queue which allows multiple messages to be posted to a
-mailbox, or as a rendez-vous point where only one message can be
-posted at a time. lwIP works with both kinds, but the former type will
-be more efficient. A message in a mailbox is just a pointer, nothing
-more. 
-
-Semaphores are represented by the type "sys_sem_t" which is typedef'd
-in the sys_arch.h file. Mailboxes are equivalently represented by the
-type "sys_mbox_t". lwIP does not place any restrictions on how
-sys_sem_t or sys_mbox_t are represented internally.
-
-The following functions must be implemented by the sys_arch:
-
-- void sys_init(void)
-
-  Is called to initialize the sys_arch layer.
-
-- sys_sem_t sys_sem_new(u8_t count)
-
-  Creates and returns a new semaphore. The "count" argument specifies
-  the initial state of the semaphore.
-
-- void sys_sem_free(sys_sem_t sem)
-
-  Deallocates a semaphore.
-
-- void sys_sem_signal(sys_sem_t sem)
-
-  Signals a semaphore.
-
-- u32_t sys_arch_sem_wait(sys_sem_t sem, u32_t timeout)
-
-  Blocks the thread while waiting for the semaphore to be
-  signaled. If the "timeout" argument is non-zero, the thread should
-  only be blocked for the specified time (measured in
-  milliseconds). If the "timeout" argument is zero, the thread should be
-  blocked until the semaphore is signalled.
-
-  If the timeout argument is non-zero, the return value is the number of
-  milliseconds spent waiting for the semaphore to be signaled. If the
-  semaphore wasn't signaled within the specified time, the return value is
-  SYS_ARCH_TIMEOUT. If the thread didn't have to wait for the semaphore
-  (i.e., it was already signaled), the function may return zero.
-
-  Notice that lwIP implements a function with a similar name,
-  sys_sem_wait(), that uses the sys_arch_sem_wait() function.
-
-- sys_mbox_t sys_mbox_new(int size)
-
-  Creates an empty mailbox for maximum "size" elements. Elements stored
-  in mailboxes are pointers. You have to define macros "_MBOX_SIZE"
-  in your lwipopts.h, or ignore this parameter in your implementation
-  and use a default size.
-
-- void sys_mbox_free(sys_mbox_t mbox)
-
-  Deallocates a mailbox. If there are messages still present in the
-  mailbox when the mailbox is deallocated, it is an indication of a
-  programming error in lwIP and the developer should be notified.
-
-- void sys_mbox_post(sys_mbox_t mbox, void *msg)
-
-  Posts the "msg" to the mailbox. This function have to block until
-  the "msg" is really posted.
-
-- err_t sys_mbox_trypost(sys_mbox_t mbox, void *msg)
-
-  Try to post the "msg" to the mailbox. Returns ERR_MEM if this one
-  is full, else, ERR_OK if the "msg" is posted.
-
-- u32_t sys_arch_mbox_fetch(sys_mbox_t mbox, void **msg, u32_t timeout)
-
-  Blocks the thread until a message arrives in the mailbox, but does
-  not block the thread longer than "timeout" milliseconds (similar to
-  the sys_arch_sem_wait() function). If "timeout" is 0, the thread should
-  be blocked until a message arrives. The "msg" argument is a result
-  parameter that is set by the function (i.e., by doing "*msg =
-  ptr"). The "msg" parameter maybe NULL to indicate that the message
-  should be dropped.
-
-  The return values are the same as for the sys_arch_sem_wait() function:
-  Number of milliseconds spent waiting or SYS_ARCH_TIMEOUT if there was a
-  timeout.
-
-  Note that a function with a similar name, sys_mbox_fetch(), is
-  implemented by lwIP. 
-
-- u32_t sys_arch_mbox_tryfetch(sys_mbox_t mbox, void **msg)
-
-  This is similar to sys_arch_mbox_fetch, however if a message is not
-  present in the mailbox, it immediately returns with the code
-  SYS_MBOX_EMPTY. On success 0 is returned.
-
-  To allow for efficient implementations, this can be defined as a
-  function-like macro in sys_arch.h instead of a normal function. For
-  example, a naive implementation could be:
-    #define sys_arch_mbox_tryfetch(mbox,msg) \
-      sys_arch_mbox_fetch(mbox,msg,1)
-  although this would introduce unnecessary delays.
-  
-- struct sys_timeouts *sys_arch_timeouts(void)
-
-  Returns a pointer to the per-thread sys_timeouts structure. In lwIP,
-  each thread has a list of timeouts which is repressented as a linked
-  list of sys_timeout structures. The sys_timeouts structure holds a
-  pointer to a linked list of timeouts. This function is called by
-  the lwIP timeout scheduler and must not return a NULL value. 
-
-  In a single thread sys_arch implementation, this function will
-  simply return a pointer to a global sys_timeouts variable stored in
-  the sys_arch module.
-  
-If threads are supported by the underlying operating system and if
-such functionality is needed in lwIP, the following function will have
-to be implemented as well:
-
-- sys_thread_t sys_thread_new(char *name, void (* thread)(void *arg), void *arg, int stacksize, int prio)
-
-  Starts a new thread named "name" with priority "prio" that will begin its
-  execution in the function "thread()". The "arg" argument will be passed as an
-  argument to the thread() function. The stack size to used for this thread is
-  the "stacksize" parameter. The id of the new thread is returned. Both the id
-  and the priority are system dependent.
-
-- sys_prot_t sys_arch_protect(void)
-
-  This optional function does a "fast" critical region protection and returns
-  the previous protection level. This function is only called during very short
-  critical regions. An embedded system which supports ISR-based drivers might
-  want to implement this function by disabling interrupts. Task-based systems
-  might want to implement this by using a mutex or disabling tasking. This
-  function should support recursive calls from the same task or interrupt. In
-  other words, sys_arch_protect() could be called while already protected. In
-  that case the return value indicates that it is already protected.
-
-  sys_arch_protect() is only required if your port is supporting an operating
-  system.
-
-- void sys_arch_unprotect(sys_prot_t pval)
-
-  This optional function does a "fast" set of critical region protection to the
-  value specified by pval. See the documentation for sys_arch_protect() for
-  more information. This function is only required if your port is supporting
-  an operating system.
-
-Note:
-
-Be carefull with using mem_malloc() in sys_arch. When malloc() refers to
-mem_malloc() you can run into a circular function call problem. In mem.c
-mem_init() tries to allcate a semaphore using mem_malloc, which of course
-can't be performed when sys_arch uses mem_malloc.
-
--------------------------------------------------------------------------------
-Additional files required for the "OS support" emulation layer:
--------------------------------------------------------------------------------
-
-cc.h       - Architecture environment, some compiler specific, some
-             environment specific (probably should move env stuff 
-             to sys_arch.h.)
-
-  Typedefs for the types used by lwip -
-    u8_t, s8_t, u16_t, s16_t, u32_t, s32_t, mem_ptr_t
-
-  Compiler hints for packing lwip's structures -
-    PACK_STRUCT_FIELD(x)
-    PACK_STRUCT_STRUCT
-    PACK_STRUCT_BEGIN
-    PACK_STRUCT_END
-
-  Platform specific diagnostic output -
-    LWIP_PLATFORM_DIAG(x)    - non-fatal, print a message.
-    LWIP_PLATFORM_ASSERT(x)  - fatal, print message and abandon execution.
-    Portability defines for printf formatters:
-    U16_F, S16_F, X16_F, U32_F, S32_F, X32_F, SZT_F
-
-  "lightweight" synchronization mechanisms -
-    SYS_ARCH_DECL_PROTECT(x) - declare a protection state variable.
-    SYS_ARCH_PROTECT(x)      - enter protection mode.
-    SYS_ARCH_UNPROTECT(x)    - leave protection mode.
-
-  If the compiler does not provide memset() this file must include a
-  definition of it, or include a file which defines it.
-
-  This file must either include a system-local <errno.h> which defines
-  the standard *nix error codes, or it should #define LWIP_PROVIDE_ERRNO
-  to make lwip/arch.h define the codes which are used throughout.
-
-
-perf.h     - Architecture specific performance measurement.
-  Measurement calls made throughout lwip, these can be defined to nothing.
-    PERF_START               - start measuring something.
-    PERF_STOP(x)             - stop measuring something, and record the result.
-
-sys_arch.h - Tied to sys_arch.c
-
-  Arch dependent types for the following objects:
-    sys_sem_t, sys_mbox_t, sys_thread_t,
-  And, optionally:
-    sys_prot_t
-
-  Defines to set vars of sys_mbox_t and sys_sem_t to NULL.
-    SYS_MBOX_NULL NULL
-    SYS_SEM_NULL NULL