Week-12 @RTEMS-GSoC-2025

Overview

This week, I completed the following tasks :

• Work on pbuf allocation for RX BDs
• Testing RX test

Work completed this week

1. Work on pbuf allocation for RX BDs
   • Worked on formulating mechanism for allocation of empty pbufs, to be filled by data received, for GRETH RX
   • GRETH requires pbufs with at maximum, 1514 bytes. So I tried allocating 32 pbufs of size 1514 bytes and attaching each to a single BD.
   • However, the actual allocation revealed that 31 pbufs of size 1516 bytes got allocated while last pbuf was of size 1452 bytes.
     
   • The pattern was like 2 extra bytes got allotted to each pbuf and this accumulated to allocation of 2*31 = 62 bytes less than 1514 (the targetted size) to last BD (i.e. 1452 bytes).
   • I tried allocationg some different sizes, and got the following results :
     • Using 1500 bytes, 1500 bytes allocated to each pbuf
     • Using 1502 bytes, 1504 bytes allocated to each pbuf
       This trend suggested that lwIP internally rounded the memory size to a memory alignment of 4 bytes
   • I also learnt that for getting the size of 1514 bytes I would need to set the macro MEM_ALIGNMENT to 2 instead of 4, which it was right now. SO keeping a size of 1516 bytes is optimal.
2. Testing RX test
   • Initially, on running the test, ARP response was being generated and sent correctly, however, ARP replies weren’t getting generated by the GRETH driver.
   • Hence, I switched to using lwIP debugging using

      [sparc/leon3]
      LWIP_DEBUG=LWIP_DBG_ON
      API_MSG_DEBUG=LWIP_DBG_ON
      ETHARP_DEBUG=LWIP_DBG_ON
      IP_DEBUG=LWIP_DBG_ON     
     

     options in a new file - config.ini, in rtems-lwip source tree. Building RTEMS lwIP package with this helped use several debug options while running the tests tx_udp.exe and rx_udp.exe with much more information, like the IP HEADER, various internal function calls, etc.

   • Using a .ini file is very useful since configuration of several BSPs can be written together at a single place.
3. Errors faced
   1. No route to host
      • This error was due to then length of pbuf passed to lwIP not initialized from the received packet, but rather uninitialized and bearing a garbage value.
      • This caused, in some cases, improper offsets at which destination address was read from the pbuf, thus causing errors like No route to host

Plans for next week

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