Week-7 @RTEMS-GSoC-2025
Published on 13 Jul 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
- 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!
- Testing GRETH lwIP Driver Initialization :
- For testing GRETH lwIP Initialization, there is a function :
greth_init_dev_and_lwip_netif()
which is used innetif_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 :- Initializing GRETH Network Interface using
greth_init_state()
- Initializing lwIP Network Interface using
greth_lwip_netif_fill()
- Initializing GRETH Hardware (including Autonegotiation with PHY) using
greth_init_hw()
- Initialize thread and semaphore for interrupt handling using
greth_init_control_structures()
- Initializing Buffer Descriptors (both transmit and receive) using
greth_init_buffer_descriptors()
- Allocate
pbufs
i.e. Packet buffers (analogous to Memory buffers in Legacy GRETH Driver) to Receive Buffer Descriptors, usinggreth_rx_pbuf_refill()
- Setting Hardware MAC Address using
greth_hw_set_hwaddr()
- Setting GRETH Interrupt Vector Number according to
sis.pdf
obtained after using command in RTEMS SIS :
>>> make sis.pdf
- Initializing GRETH Interrupt Handler using
greth_install_interrupt_handlers()
And finally, this was successful :
- Initializing GRETH Network Interface using
- Errors Faced during lwIP Build Process :
- Errors during Buffer Descriptors Initialization, which, afte using
gdb
, were found out to be withalmalloc()
function ingreth_netif.c
.
First tried undefining any other definitions ofmalloc()
, if present, so as to use its original definition, as in Legacy GRETH Driver; however, this made no change in the error.
However, internallyalmalloc()
was usingaligned_alloc()
which requires parameters of typesize_t
; but earlier was using a macro defined constant as its parameter; so I asigned the macro value to asize_t
variable and the error with Buffer Descriptors Initialization was solved. - 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. - 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 insys_request_irq()
, which I received for this, meaningRTEMS_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.
- Errors during Buffer Descriptors Initialization, which, afte using
- For testing GRETH lwIP Initialization, there is a function :
- 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 inrtems-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.. 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
- Tried using DHCP in
telnetd02.exe
fromrtems-net-legacy
so as to test GRETH Legacy Driver, using approaches like removing all static IP addresses fromconfig.inc
, setting all IP related fields toNULL
innetwork-config.h.in
, usingdnsmasq
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.
- There was network configuration set up to a great extent at
- 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 fromrtems-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. telnetd02.exe
application from RTEMS LEgacy Networking, has a commandnetstats
using which, dteailed statistics regading the recent communication session, could be obtained. The statistics for the above result shown proper statistics.- Further, using
netcast
I was also able to transmit custom UDP packets to the Legacy GRETH Driver and it shown proper reception. - After checking that my unicast UDP client test works, I pushed it to my branch of my fork of RTEMS Networking Tests
- 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,
Plans for next week
- Working actively on completing code for GRETH lwiP Driver transmission mechanism
- Working on testing GRETH lwIP Driver mechanism using tools like Wireshark
- Try debugging GRETH Legacy Driver simulation in SIS
- Work on completing goals of Midterm evaluation and create a blog post for the progress until midterm evaluation
- Create blog for Week-8