week11 @RTEMS-GSoC-2025

Overview

This week, I completed the following tasks :

• Modify code to include TX and RX channels structs in struct greth_netif_state
• Learnt in depth about Legacy and lwIP networking stacks
• Packet tarnsmission observed in Wireshark
• Studied behaviour of ARP requests transmitted by GRETH lwIP driver
• Fixed bug regarding memory alignment in the driver TX mechanism
• Fixed bug regarding descriptor alignment and memory allocation to TX descriptors

Work completed this week

1. Modify code to include TX and RX channels structs in struct greth_netif_state
   • Before chaning the code, I tried commenting out RX descriptor part to cheeck what could be causing a memory alignment issue whichwas arising in this case.
   • So, I made a custom approach, using pbuf_free() from lwIP, which frees a pbuf chain starting from given head.
   • My approach jumps as much buffer descriptors as much pbufs are needed to contain that packet, and then frees that whole pbuf chain.
2. Learnings regarding Legacy and lwIP networking stacks :
   • In legacy networking, the driver is rsponsible to dequeue mbufs from transmit queue using methods like IFDEQUEUE() and allocate them to free descriptors; while, in lwIP, this scenario is handled by the networking stack itself. Hence, I can directly give a struct *pbuf argument to netif->linkoutput function, since lwIP calls this function with the pbuf to be sent [here it is greth_send() or greth_send_gbit()] and lwIP networking stack will handle the dequeuing.
   • In legacy networking stack the driver is responsibke to empty the transmit queue as well as retry for failed packets, while in lwIP, packet retransmissions as well as continuous transmission is handled internally.
3. Packet tarnsmission observed in Wireshark
   • As confirmed from the debug printf() statements whole of greth_send() code is executed and descriptors are not already allocated so can be used.
   • The descriptors address increment by precisely 8 bytes, as expected, after the descriptor structure was reformed.
4. Behaviour of ARP requests transmitted by GRETH lwIP driver :
   • Each UDP message is transmitted by the test after every 3 seconds initially. But I observed that for every messsage, 5 descriptors were being used.
   • This set of descriptors constituted a set of 5 ARP requests.
   • The test intends to send UDP packets to a specified IP address and port, but, that receiver is down, (which is alright for now), i that case we expect ARP requests broadcast from the transmitter asking the MAC address of the receiver, for successfully communicating the packet. The goal of this test was to capture these ARP requests.
   • Now at this stage, I was able to capture these ARP requests successfully, confirming the GRETH transmission mechanism being active and working!
   • The requests were being sent with delays of 0.3s-1s-1s-1s
   • 
5. Bug regarding memory alignment in the driver TX mechanism
   • I observed that when my message length was a multiple of 8 like 8/16 characters only then successful transmission occured; while, when it was some other length, I got memory alignment error from SIS.
   • To check in detail, I used sparc-rtems7-gdb and learnt that the error was embedded deep into lwIP source code during memory operations.
   • I tried using iprintf() statements to check the address being used where this trap error occurs, and observed it was at a non-aligned address.
   • Checking further I learnt that alignment in lwIP is controlled by the macro MEM_ALIGNMENT, however, there was no definition of this macro for GRETH drievr available at that time in the code. Figured out, I had to use that macro with proper value (here, 4).
   • I further checked the definitions of all the uses of this macro in the code and found that the most relevant definition was in rtems-lwip/rtemslwip/include/legacy_lwipopts.h. So I included this file in rtems-lwip/rtemslwip/gret/lwipbspopts.h and this solved the issue - which I confirmed by sending 14 character strings successfully!
6. Bug regarding descriptor alignment and memory allocation to TX descriptors
   • Another problem I encountered was that after few cycles through all descriptors, I was getting the next descriptor busy, i.e. driver was not resetting the TX_EN flag of control field of the descriptor.
   • Upon further inspection I realised, as told by mentors, that there were 2 problems with my code :
     1. The descriptor alignment was wrong. I corrected it according to the correct formula :
        • 
     2. Memory allocation was improper for TX descriptor, fixed it :
        • 

Plans for next week

1. Work on gettig expected results from GRETH lwIP driver transmission mechanism

2. Start with reception mechanism code atleast to some extent