Week-8 @RTEMS-GSoC-2025

Overview

This week, I completed the following tasks :

• Creating a UDP test which sends UDP packets every fixed interval, using the GRETH lwIP driver and regsitering it as a command in RTEMS Shell, created as an RTEMS application in lwIP package
• Creating a report in the form of blog, for the progress of this project till midterm.

Work completed this week

1. Creating a UDP test which sends UDP packets every fixed interval, using the GRETH lwIP driver and regsitering it as a command in RTEMS Shell, created as an RTEMS application in lwIP package :
   • To test the newly created transmission capability of GRETH lwIP Driver, as guided by my mentors I created a test application in RTEMS lwIP package, which spawns a shell and registers a custom command - udp, to transmit UDP packets every fixed interval, using GRETH lwIP interface.
   • This test was very much similar to the UDP client test which I had used to test GRETH Legacy Driver.
   • The plan was to create a socket configured for IPv4 and UDP protocol, and transmit packets every fixed interval, to an IP address which lies in the same subnet as GRETH lwIP driver. When the destination peer address fails, the lwIP stack should broadcast ARP packet, which can be observed on Wireshark.
   • Here’s the application that I have created so far for this test : UDP test
   • However, this approach didn’t seem to work.
   • The first problem was that, it was expecte upon the application startup, since GRETH lwIP dirver was registered in lwIP stack, a tap interface would be created which would attach to the bridge specified in the SIS startup command - sudo ./sis -v -leon3 -bridge lxcbr0 ./udp_test.exe. However, the bridge was not created and this caused problem to form a complete virtual network to monitor the packets transmitted by the driver.
   • Using debug printf statements I chevcked whether the proper transmission function i.e. greth_send() or greth_send_gbit() was linked to the lwIP stack in the field netif->linkoutput which handles raw packet transmission, and this was observed to be mapped correctly.
   • I also noticed, that in Legacy GRETH driver, when struct rtems_bsdnet_ifconfig was used, it used RTEMS_BSP_NETWORK_DRIVER_ATTACH macro, which expands to anotehr macro - RTEMS_BSP_NETWORK_DRIVER_ATTACH_GRETH which further expands to the function rtems_leon_greth_driver_attach(). This function extracts the base address for GRETH registers by scanning the AHB slave interfaces and then resets the GRETH Module. then it calls rtems_greth_driver_attach() which further helps link the GRETH Legacy Driver to Legacy Netowkring stack and iniialize various related variables. However, I observed no such function was present for GRETH lwIP Driver. So I decided to create an analogous function for lwIP at rtems-lwip/embeddedsw/sparc/leon_greth.c : function
   • Thi approach provided some improvements - the GRETH autonegotiation gave back non zero values indficating a successfull autonegotiation attempt. Unfortunately, the tap interface was still not created, giving net: hwaddr error. On navigating in RTEMS SIS codebase, I got some insights at tap.c that this error was due to failed SIOCSIFHWADDR ioctl() call, that is used to set the hardware address of a network interface.
   • The analysis further shown that in rtems-sis/greth.c the GRETH control register should not have CTRL_RE flag set.
   • There might be a case, when CTRL_RE bit is set before MAC address is properly configured, and then subsequently disabled or enabled, and finally, just before the MAC address is set, the driver is setting CTRL_RE bit due to which MAC address is not propagating to SIS resulting in failure in tap interface creation.
   • This seemed to be the exact issue - in greth_netif.c in greth_hw_init() which initializes GRETH hardware, CTRL_RE flag is set, then long after that MAC address is set in GRETH registers using greth_hw_set_hwaddr(). On changing the sequence by shifting greth_hw_set_hwaddr() before greth_hw_init() and the issue got solved
     
2. Creating a report in the form of blog, for the progress of this project till midterm :
   • I created a detailed report for the progress of this project till midterm.
   • This report can be found here : Pre-Midterm Progress till Midterm Report

Plans for next week

1. Work on the feedback received for the GRETH driver, like descriptor algnment, buffer descriptor structure, etc.
2. Simulate GRETH lwIP driver transmission mechanism