Avatar Blogs during GSoC-2025 period at RTEMS for the project - Providing SPARC GRETH Network Drivers for lwIP

Week-7 @RTEMS-GSoC-2025

Overview


This week, I completed the following tasks :

  • Resolving errors and building RTEMS lwIP package successfully for the first time for SPARC/LEON3 BSP
  • Ensure successful initialization of GRETH lwIP driver using telnetd01.exe test from RTEMS lwIP Package
  • Tried new approach for testing Legac GRETH Driver, using 2, same TTCP tests, but different network configurations and trying to connect them
  • Successfully testing Legacy GRETH Driver using an UDP Client which transmits packets successfuly every second and confirming their reception on the Legacy GRETH Drievr, as well as using netcat for sending packets in similar way, but now using custom UDP Packets

Work completed this week


  1. Resolving errors and building RTEMS lwIP package successfully for the first time for SPARC/LEON3 BSP :
    • I faced a lot of errors while building RTEMS lwIP Package, which included linker errors, syntax errors, data type errors, typos, etc.
    • Howvever, resolving all of them, I finally was able to build the RTEMS lwIP package successfully with the new code for GRETH lwIP Driver Initialization! With no errors or warnings! lwip_successful_build
  2. Testing GRETH lwIP Driver Initialization :
    • For testing GRETH lwIP Initialization, there is a function :
      greth_init_dev_and_lwip_netif()
      which is used in netif_add() function, which is core lwiP function for registering network interfaces with lwIP Networking Stack. This function calls several other functions which initialize various other aspects and components of the driver, like :
      1. Initializing GRETH Network Interface using greth_init_state()
      2. Initializing lwIP Network Interface using greth_lwip_netif_fill()
      3. Initializing GRETH Hardware (including Autonegotiation with PHY) using greth_init_hw()
      4. Initialize thread and semaphore for interrupt handling using greth_init_control_structures()
      5. Initializing Buffer Descriptors (both transmit and receive) using greth_init_buffer_descriptors()
      6. Allocate pbufs i.e. Packet buffers (analogous to Memory buffers in Legacy GRETH Driver) to Receive Buffer Descriptors, using greth_rx_pbuf_refill()
      7. Setting Hardware MAC Address using greth_hw_set_hwaddr()
      8. Setting GRETH Interrupt Vector Number according to sis.pdf obtained after using command in RTEMS SIS :
        >>> make sis.pdf
        GRETH_IRQ_NUM
      9. Initializing GRETH Interrupt Handler using greth_install_interrupt_handlers()
        And finally, this was successful : GRETH_successful_init
    • Errors Faced during lwIP Build Process :
      1. Errors during Buffer Descriptors Initialization, which, afte using gdb, were found out to be with almalloc() function in greth_netif.c.
        First tried undefining any other definitions of malloc(), if present, so as to use its original definition, as in Legacy GRETH Driver; however, this made no change in the error.
        However, internally almalloc() was using aligned_alloc() which requires parameters of type size_t; but earlier was using a macro defined constant as its parameter; so I asigned the macro value to a size_t variable and the error with Buffer Descriptors Initialization was solved.
      2. Error during thread creation : the thread, to be used for interrupt handling, was not getting created properly. Upon inspection, I found that the name of the thread wasn’t set properly. So providing it a 4 character string, (I used "GRLW") solved the issue.
      3. I got error while installing Interrupt Handler. Earlier, I was using 2 interrupt handlers, one for transmission related interrupts and one, for reception related interrupts. And, the error code 26 for the rtems_interrupt_handler_install() function, used internally in sys_request_irq(), which I received for this, meaning RTEMS_NO_MEMORY, indicating insufficient memory resources. Increasing task stack size did resolve this issue, but I chose the approach of using a single interrupt handler for both transmit and receive interrupts, similar to GRETH Legacy Driver.
  3. Tried new approach for testing Legac GRETH Driver, using 2, same TTCP tests, but different network configurations and trying to connect them :
    • There was network configuration set up to a great extent at
      rtems-net-legacy-demos/networkconfig-icecube.h.
    • I thought to use this header file in ttcp tets in rtems-net-legacy-deoms to set up TTCP with a specific configuration. Then, to make 2 such resultant executables, ttcp.exe, with 2 configurations (different IP Addresses, MAC Addresses, Network Intrface names, Host names and domain names), then run then in separate SIS instances and set up TTCP Transmitter in one, and receiver in another. However, in spite of this setup, the communication didn’t seem to occur as expected. ttcp_two_1. Only few packets were observed, that too being transmitted from both sides, which wasn’t expected.
    • In the end, after 5 such packets transmitted from transmitter side, timeout occured, but only at the transmitter end. And following it, detailed statistics of last communication session were displayed ttcp_stats
    • Tried using DHCP in telnetd02.exe from rtems-net-legacy so as to test GRETH Legacy Driver, using approaches like removing all static IP addresses from config.inc, setting all IP related fields to NULL in network-config.h.in, using dnsmasq server for DHCP etc., but DHCP didn’t seem to run, as no Dynamic IP Address was assigned to Legacy GRETH Driver being simulated in SIS.
  4. Successfully testing Legacy GRETH Driver using an UDP Client which transmits packets successfuly every second and confirming their reception on the Legacy GRETH Drievr, as well as using netcat for sending packets in similar way, but now using custom UDP Packets :
    • Finally, I was able to test Legacy GRETH Driver using a UDP Unicast Client, which sent UDP packets to Legacy GRETH Driver IP Address, every second. During this testing, telnetd02.exe application from rtems-net-legacy was used.
    • For this test, I took reference from this multicast client test : RTEMS Networking Tests
    • This was verified by monitoring the UDP Packets received by Legacy GRETH Driver using tcpdump utility. tcpdump_ucast
    • telnetd02.exe application from RTEMS LEgacy Networking, has a command netstats using which, dteailed statistics regading the recent communication session, could be obtained. The statistics for the above result shown proper statistics. tcpdump_netstats
    • Further, using netcast I was also able to transmit custom UDP packets to the Legacy GRETH Driver and it shown proper reception. netcat_netstats
    • After checking that my unicast UDP client test works, I pushed it to my branch of my fork of RTEMS Networking Tests

Plans for next week


  1. Working actively on completing code for GRETH lwiP Driver transmission mechanism
  2. Working on testing GRETH lwIP Driver mechanism using tools like Wireshark
  3. Try debugging GRETH Legacy Driver simulation in SIS
  4. Work on completing goals of Midterm evaluation and create a blog post for the progress until midterm evaluation
  5. Create blog for Week-8