Modified Simple Socket Server (Interfaces)

During the past few weeks I have been continuing on trying to get the second interface to work on the modified simple socket server example.    The verilog file has been changed once again to force enable the opening of the second interface (eth1).  Most of the work trying to get the second interface to work involved manipulating/hacking some files within the Altera BSP plugin in Eclipse.  The main files that I have been looking at were particularly ones inside the driver folder of the board support package provided by Altera, particularly on ins_tse_mac.c, altera_avaolon_tse_system_info.c, altera_avalon_tse.c and their respective C Header files in the 'inc' folder.   ins_tse_mac.c contains the methods used to configure the TSE MACs and the public API for the TSE driver. 


The most important method in that file to enable the use of multiple interfaces is  alt_tse_system_add_sys, which defines and adds a TSE system/interface onto an array that will be read to tell the board that a second interface is available to use.  For now, I am assuming that this method will be used twice; one for the first interface and one for the second interface.  The reason I am using it twice is because the simple socket server's default assignment only allows the use of one interface (eth0), so it must be overridden to make use of more than one interface. The file in which I used the add_sys function is in alt_sys_init.c, which is the HAL initialization source file.  Before add_sys can be called though, the objects used to pass into as parameters for add_sys had to be instantiated, such as 'sys_mac_0 = {TSE_SYSTEM_MAC(TSE_MAC_0)};' with type 'alt_tse_system_mac'.  The name TSE_MAC_0 inside TSE_SYSTEM_MAC comes from the names given by system.h, which is created by the the configuration given by the SOPC builder. In other words, the names used to create these objects for add_sys must be exactly named as configured by the system.h file/SOPC builder.


After adding the functions mentioned above, Matt and I tried testing out the program on the DE4 board and the board can then detect and prepare two interfaces.  Based on the debug messages from the program, each TSE MAC has their own physical address in memory as it should (and exactly the ones configured in SOPC builder) and links for the PHYs for both interface can be established.  The first time we tested this out though, our DHCP was not working and we got unreasonable IP addresses (not part of the subnet of the router's IP address) that we couldn't even ping/telnet to.  Unfortunately, we found out the reason for all this trouble is because of a dialog box that must not be closed in the JTAG programmer program, which enables the forwarding of packets to the board (OpenCore Plus IP).  Once we realized that, we tested the program out again and DHCP works again.

As of now, the NicheStack has to be modified so messages can be received and queued asynchronously using both interfaces and then processed synchronously by the server.  I am particularly looking at the os_q.c file contained in the UCOSII folder, which contains the queue management functions for the RTOS.  A DHCP server must also be implemented for the board at the moment.